So far I have been using a volume integration over wdot_tot from the Efield_2D.vtk file to renormalize all quantities computed by AORSA. Now I am not so sure anymore if this is actually the correct way of doing things.
From AORSA I get this:

 Species absorption from Estar dot J:
         power absorbed by electrons = 0.84159E+06 Watts  =    84.1590 %       
     power absorbed by majority ions = 0.15841E+06 Watts  =    15.8410 % 
 Species absorption from Wdot:
         power absorbed by electrons = 0.35175E+06 Watts  =   100.0000 %  
Species absorption from quasilinear Wdot:
         power absorbed by electrons = 0.58096E+06 Watts  =   100.0000 % 

I know that Estar dot J is not good, but then there are two wdots out there, only one of which ends up in the .vtk file.
Is the wdot_tot in the .vtk File even in W/m^-3?
This inquiry is motivated by us getting vastly different density fluctuations between the cold plasma approximations and AORSA.

It it too easy to just run out of memory without knowing how many nodes to request. I will dig out my script for estimating this, and perhaps add to the code a --pretend flag to look at memory usage before submission.

Dear AORSA community,
Not really an issue, but I would like a second opinion on my AORSA results. I attached a pdf of the absolute values of the electric field and the kx, ky mode amplitude plot from the aorsa2d.ps.
The result is very different from my GENRAY and COMSOL calculations and I am not sure whether this is due to the lack of resolution in the x direction or something else.
Any pointers would be much appreciated!
With kind regards
Severin
AORSA_E_abs.pdf
Resolution_AORSA.pdf
aorsa2d.txt

Hello,
I am trying to make use of the free NERSC time up for grabs at the moment. Last night I ran my first case with full ion absorption, but then noticed that my resolution was insufficient, afterward.
So my case is as follow
448 x 384 grid size
96x64 nprow and npcol
256 nodes
The code crashes right after printing the "n capr_bpol_mid" table.
The error message is:
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
xaorsa2d 000000002033FE13 for__signal_handl Unknown Unknown
libpthread-2.26.s 00002AAAB19F92D0 Unknown Unknown Unknown
libsci_intel_mpi. 00002AAAABE53EE6 blacs_barrier_ Unknown Unknown
xaorsa2d 000000002020F486 Unknown Unknown Unknown
xaorsa2d 000000002000CC12 Unknown Unknown Unknown
libc-2.26.so 00002AAAB1C2934A __libc_start_main Unknown Unknown
xaorsa2d 000000002000CB2A Unknown
P.S. I just woke up after submitting runs till late at night, I can provide whatever information you need later.

I am working on the AORSA GUI and I noticed an inconsistency with the number of species considered in AORSA.

It seems that all iterations over species are hardcoded in AORSA, i,e, split into 6 separate lines always assuming 6 separate species. Could this be a potential performance issue?
It seems that iterations over species are only performed in aorsa2dMain.F, so replacing he separate lines by proper for-loops with a variable specifying the number of considered species might not involve much work. If you disagree with this, let me please know so I have a better feel for the scope of the aorsa restoration project.

S_nspec seems to be already in place for the number of species iterations but it is never used. Also, Cornwall's input file is inconsistent with a total of 4 thermal (S_NSPEC_TH = 4) + 2 (default for n_spec_nm_max) fast ion species being declared, but S_nspec specified to be 2 and a total of 5 profiles supplied.

I just wanted to let you know about this.

It seems that the ps lost all text. When I ran AORSA back in May all the graphs in aorsa2d.ps had labels, but they are all gone in the file from my 128 MHz helicon computation (I repeated it today). The old aorsa2d.ps is also two times larger.
I checked the file with 3 viewers: Ghostviewer on windows, acrobat distiller on windows, and ghost viewer on windows subsystem Linux.
Maybe it is necessary to recompile pgplot?

I am not sure whether I want to submit my full-scale AORSA calculation now, since I only know how to diagnose my AORSA runs with these plots.

Any advice would be helpful.

I attached all the usual output and the PDF I got from acrobat distiller, since PS is not supported here. I also attached the first 11 pages from the AORSA run I did in May.

log_aorsa2d.txt
out15.txt
aorsa2d_in.txt
aorsa2d.PDF
aorsa2d_may_excerpt.PDF

AORSA does not work for 257x257 EQDSK files due to hardcoded matrix shape. SHould read shape from EQDSK-file, ideally.

moving HOWTO.md content to README.md - just to keep the number of instructional files down and all the info in one place - which appears on the landing page for the code.

@jcwright77

I could make use of the free NERSC time this weekend and I managed to get AORSA calculations for 11 mode numbers. Now I am trying to calculate the density perturbations in 3D space. If I am not mistaken, this should be completely analogous to the electric field, and I just have to carry out the sum over mode numbers, e.g. (3) from Jaeger et al (2002). However, this would mean that the n_tilda in Efield_2D.vtk is a Fourier coefficient and should be complex. But in the output, I can only find ntilda_e_real and there is no entry for ntilda_e_imag.

It seems that the memory requirements of the wdot calculations went up significantly after I recompiled AORSA. Is it expected that the wdot calculation (with nzeta_wdote = 51, nzeta_wdoti = 0), consumes (a lot) more memory than ScaLAPACK?

My last AORSA calculation on 288 nodes with a 448x448 grid died with OUT_OF_MEMORY with the last log entries:

xjx_max =   3.435404960082567E-008
xjy_max =    322.488306213783     
xjz_max =   0.000000000000000E+000
xkprl_max =    169.774443965673     
xkprl_pos_min =   0.272853307515924     
xkprl_neg_max =  -0.272900817877951     
xkprl_min =   -110.200249742706     
time to calculate currents =    1.048 min

In the past, I have done calculations with a 384x384 grid 128 nodes, but this also produces the same OUT_OF_MEMROY errr now.
The problem is that the AORSA does not scale linearly, so the more nodes I assign the lower the performance of ScaLAPACK. E.g. 16.198 GFlops on 128 nodes and 13.515 on 288.

My NERSC allocation is much smaller this year, so it is important to squeeze as much performance out of my hours as possible. Any suggestions?

So people can look at the webpage, rather than the source files

Hello, authors.I need to run this software on centos, but I'm having some problems with it and I'm asking you guys for advice.

Here I made some changes to the makefile. ifeq ($(shell cat /etc/os-release | grep -qEi 'centos'; echo $$?),0) # Centos #ifeq ($(UNAME_R),18.7.0) include makeopts.centos $(info System identified as centos) SYSTEM_IDENTIFIED = 1 #endif endif
corresponding makeopts.centos is `include compileropts.gnu

FC = mpif90

pgplot

#LIBS += -L/usr/lib/ -lpgplot

netcdf

NETCDF_DIR = /public/home/zhangzl/software/netcdf4-needed/lib
LIBS += $(NETCDF_DIR)/libnetcdff.a -L $(NETCDF_DIR) -lnetcdf
INCLUDE_DIRS += -I /public/home/zhangzl/software/netcdf4-needed/include

scalapack

LIBS += -L /public/home/zhangzl/software/scalapack-2.2.0
/public/home/zhangzl/software/BLAS-3.12.0/lib/libblas.a
/public/home/zhangzl/software/BLACS/LIB/blacs.a
/public/home/zhangzl/software/BLACS/LIB/blacsF77init_MPI-LINUX-0.a
/public/home/zhangzl/software/BLACS/LIB/blacsCinit_MPI-LINUX-0.a
/public/home/zhangzl/software/BLACS/LIB/blacsF77.a
/public/home/zhangzl/software/BLACS/LIB/blacs_MPI-LINUX-0.a `

The compileropts.centos is COMMON_OPTION = -save -r8 #-i8 COMMON_OPTION2 = -r8 #-i8 COMMON_OPTION3 = COMMON_OPTION4 = -r8 #-i4 MOD_DIR_FLAG = -module $(MOD_DIR)

Now when I do the make operation, I run into some problems
①(.text+0x20): undefined reference to main'
obj/ql_myra.o: In function __ql_myra_mod_MOD_ql_myra_write': ql_myra.f:(.text+0x11744): undefined reference to blacs_barrier_'
obj/wdot_test.o: In function __wdot_mod_MOD_wdot_new_maxwellian': wdot_test.f90:(.text+0xa6c0): undefined reference to blacs_barrier_'
obj/current.o: In function current_orbit_': current.f:(.text+0x17c4f): undefined reference to fftn2_'
current.f:(.text+0x245c2): undefined reference to blacs_barrier_' obj/current.o: In function ntilda__':
current.f:(.text+0x2b22e): undefined reference to blacs_barrier_' obj/current.o: In function current_':
current.f:(.text+0x33792): undefined reference to blacs_barrier_' obj/current.o: In function current_1_':
current.f:(.text+0x3d416): undefined reference to blacs_barrier_' obj/current.o: In function current_2_':
current.f:(.text+0x459f2): undefined reference to blacs_barrier_' obj/current.o:current.f:(.text+0x49f11): more undefined references to blacs_bar rier_' follow
obj/setupblacs.o: In function setupblacs_': setupblacs.f:(.text+0x5f): undefined reference to blacs_pinfo_'
setupblacs.f:(.text+0x8a): undefined reference to blacs_setup_' setupblacs.f:(.text+0xa5): undefined reference to blacs_get_'
setupblacs.f:(.text+0xf9): undefined reference to blacs_gridinit_' setupblacs.f:(.text+0x38d): undefined reference to blacs_gridexit_'
setupblacs.f:(.text+0x4fd): undefined reference to blacs_get_' setupblacs.f:(.text+0x521): undefined reference to blacs_gridinit_'
setupblacs.f:(.text+0x545): undefined reference to blacs_gridinfo_' obj/rf2x_setup2.o: In function run_rf2x_':
rf2x_setup2.f:(.text+0x3f25): undefined reference to rhograte_' rf2x_setup2.f:(.text+0x3f6a): undefined reference to rhograte_'
rf2x_setup2.f:(.text+0x3faf): undefined reference to rhograte_' rf2x_setup2.f:(.text+0x3ff4): undefined reference to rhograte_'
rf2x_setup2.f:(.text+0x4039): undefined reference to rhograte_' obj/rf2x_setup2.o:rf2x_setup2.f:(.text+0x407e): more undefined references to rh ograte_' follow
obj/read_cql3d.o: In function __read_cql3d_MOD_netcdfr3d': read_cql3d.f90:(.text+0x205): undefined reference to __netcdf_MOD_nf90_open'
read_cql3d.f90:(.text+0x347): undefined reference to __netcdf_MOD_nf90_inq_dimi d' read_cql3d.f90:(.text+0x411): undefined reference to __netcdf_MOD_nf90_inq_dimi d'
read_cql3d.f90:(.text+0x4db): undefined reference to __netcdf_MOD_nf90_inq_dimi d' read_cql3d.f90:(.text+0x5a5): undefined reference to _netcdf_MOD_nf90_inq_dimi d'
read_cql3d.f90:(.text+0x66f): undefined reference to __netcdf_MOD_nf90_inq_dimi d' read_cql3d.f90:(.text+0x73f): undefined reference to netcdf_MOD_nf90_inquire dimension'
read_cql3d.f90:(.text+0x81a): undefined reference to ncdinq_' read_cql3d.f90:(.text+0x844): undefined reference to ncdinq'
read_cql3d.f90:(.text+0x86e): undefined reference to ncdinq_' read_cql3d.f90:(.text+0x898): undefined reference to ncdinq'
read_cql3d.f90:(.text+0x19cc): undefined reference to __netcdf_MOD_nf90_inq_var id' read_cql3d.f90:(.text+0x19eb): undefined reference to __netcdf_MOD_nf90_get_var _eightbytereal'
read_cql3d.f90:(.text+0x1a83): undefined reference to __netcdf_MOD_nf90_inq_var id' read_cql3d.f90:(.text+0x1ab6): undefined reference to __netcdf_MOD_nf90_get_var _1d_eightbytereal'
read_cql3d.f90:(.text+0x1ad5): undefined reference to __netcdf_MOD_nf90_inq_var id' read_cql3d.f90:(.text+0x1b08): undefined reference to __netcdf_MOD_nf90_get_var _1d_fourbyteint'
read_cql3d.f90:(.text+0x1b3f): undefined reference to __netcdf_MOD_nf90_inq_var id' read_cql3d.f90:(.text+0x1b72): undefined reference to __netcdf_MOD_nf90_get_var _2d_eightbytereal'
read_cql3d.f90:(.text+0x1b91): undefined reference to __netcdf_MOD_nf90_inq_var id' read_cql3d.f90:(.text+0x1bc4): undefined reference to __netcdf_MOD_nf90_get_var _1d_eightbytereal'
read_cql3d.f90:(.text+0x1be3): undefined reference to __netcdf_MOD_nf90_inq_var id' read_cql3d.f90:(.text+0x1c16): undefined reference to __netcdf_MOD_nf90_get_var _3d_eightbytereal'
read_cql3d.f90:(.text+0x1d76): undefined reference to __netcdf_MOD_nf90_inq_var id' read_cql3d.f90:(.text+0x1da9): undefined reference to __netcdf_MOD_nf90_get_var _2d_eightbytereal'
read_cql3d.f90:(.text+0x215b): undefined reference to __netcdf_MOD_nf90_inq_var id' read_cql3d.f90:(.text+0x218e): undefined reference to __netcdf_MOD_nf90_get_var _2d_eightbytereal'
read_cql3d.f90:(.text+0x23f0): undefined reference to __netcdf_MOD_nf90_close' collect2: error: ld returned 1 exit status make: *** [xaorsa2d] Error 1

② If I compile with mpifort, the error is reported as src/CQL3D_SETUP/read_cql3d.f90(35): error #7013: This module file was not generated by anyrelease of this compiler.[NETCDF] use netcdf ------∧ src/COL3D_SETUP/read cql3d.f90(432):internal error:Please visit 'http://www.intel.com/sotware/products/support' for assistance. if ( iret .ne. NF90_NOERR) then [Aborting due to internal error. ] compilation aborted for src/CQL3D_SETUP/read cql3d.f90(code 1) make: ***[obi/read cql3d.o]Error 1

I performed a scan on the antenna position with AORSA. When moving the antenna away from the boundary I noticed that I get a lot less spurious modes in the calculation. This also removes the noise from ntilda. However, as a side effect, this causes a second beam to be created due to power being reflected back from the boundary into the plasma (see Re_E_alpha.pdf).

To compensate for this I set psilim=psiant=0.85, which yielded a clean simulation without any noise in ntilda and no discernible second beam.

However, since psilim is just psi at the separatrix and it does not define the boundary directly. This leads to some other strange features as I reported in #35.

So the question that I have is there any way I can move the boundary inwards properly?

Please note that I still have a lot of CPU time to spend on NERSC (8 million hours), and each week that passes without any replies, it becomes more and more unlikely that I can deplete my account before the end of December.

I recently did a scan of the antenna position with AORSA. The goal was to determine if there is a sweet spot that would suppress reflections off the boundary. By moving the antenna inwards, the overall convergence got much better, but the calculation shows second beam that is created by a reflection at the boundary.

I checked the source code and the boundary is controlled through psilim. I set both psiant and psilim to 0.85. Note that I left rhomax at 1.0 since it does not seem to affect the boundary. This resulted in the cleanest AORSA calculation I have to date with no reflections that I can see.
However, it seems that in this case, the antenna is outside the boundary???
Please find attached the corresponding graph, and the aorsa2d.in (with txt file ending).

The waves actually seem to originate from outside of the boundary. Does anybody understand what is happening here?

I have tried to run the DIII-D shot 165908, which is the demonstration case for off-axis helicon heating.
This shot has only 1.5 T magnetic field resulting in very large k_perp. I first ran the case at 2.0 T to establish the resolution needed for that case. I ended up with 512x360, which is large, but without wdot it can be handled by 288 nodes in 130 minutes total.
Using the cold plasma dispersion relation I estimated that I need to increase the resolution to 768x432 to get a converged case at 1.5 T.
Assuming that solving the matrix equation scales with N^3 (N=nmodesxnmodesy) I assumed that the CPU time would increase by 1.8^3=5.83. Accordingly, I assigned 1152 nodes for the task which was an increase in the number of cores by a factor of 4.
Since the original calculation took 130 minutes, one would expect this task to run for 130 * 5.83 / 4 = 190 minutes.
Unfortunately, the task timed out after 12 h giving me no information on how long SCALAPACK really needs to invert this matrix.
When I fit T = AN^n with T the minutes scalapack needs times the number of processors used to my previous runs I get n=3.2. If I extrapolate from that the 36864 CPUs that I am using should have solved this problem in about 100 minutes << than the 450+ that it did use. Please note that assembling the matrix took already 128 minutes. This is the one piece of information I learned from this attempt. This seems to scale with the square of the grid size.

So the questions here are:
a) Does anybody know what is happening here?
b) Do you have tips on how I can diagnose this without wasting another 1.5 million CORI hours?

Hello,
Module pgplot appears as a required module in the readme but it is never loaded in the instructions via the "module load" command. Afaik it is not directly available on cori as a module. Is it maybe encapsulated in another module? Running AORSA without pgplot causes:
error while loading shared libraries: libpgplot.so

Installing and building pgplot also does not seem 100% straightforward.
Please help,
with kind regards
Severin

We need documentation for creating / modifying the following inputs ...

• Density
• Temperature
• Z effective

Dear AORSA community,
Over the last 2 years I have noticed an enormous increase in AORSA's memory requirements.
My first calculations used 128 Cori nodes to handle calculations grids with a resolution of up to 384x384 with nzeta_wdote=51, and nzeta_wdoti=0.
While the source code has not changed during this time, such calculations will not run today, and instead will terminate with a bus error during the computation of the electron QL operator.
Last week I tried to run a calculation with the same wdot settings, and a grid of 320x256 on 512 nodes. For large mode numbers 89-91 this worked, but anything below that crashes again at the same point. Increasing the amount nodes any further will have diminishing returns, and experimenting with it is extremely costly as AORSA only crashes towards the end of the calculation.
Is there anything that can be done to figure out what has happened to AORSA over these 2 years? Is this something people at NERSC could help us with?
We are getting towards the helicon experiments, and AORSA is a vital arrow in our quiver. In its current state, it is prohibitively expensive exclusively due to its memory requirements, especially for toroidally resolved calculations which will be needed for many physics validation studies. Please help.
batchscript.txt
aorsa2d.txt

Summary of status for resurrecting the PCI synthetic diagnostic for DIII-D helicon case.

@cornwalllau placed the most recent runs for here at NERSC ...

/global/project/projectdirs/m77/Lau

One is an ITER case without SOL. The other is a DIII-D run with the SOL.

@nbertell points out there does appear to be a ntilda_e_real variable in the Efield2D.vtk file, which is likely the density variation required for the PCI synthetic diagnostic.

@jcwright77 is going to look for the scripts written by @ntsujii and then will add them to the repo.

Notes from @ntsujii

If you will be using my codes as the basis for doing synthetic PCI,
you will also need to write the part where the toroidal mode number
spectrum is calculated, which is used for summation of all nphi modes.
In addition, if there is any change in the 'fpm' file format since I
have left (there may well be one or two additional variables), this
should be applied to 'aorsaconv.F90' that converts 'fpm' to netcdf
file used in my IDL suite of codes.

Is it possible/sensible to run AORSA if the absorption of the waves is poor enough that it will take the waves multiple passes around the vessel for them to be absorbed? Currently, I am looking at a case that has probably less than 20% "single pass" absorption.

Dear AORSA community,
The parameters in aorsa2d.in are: nboundary=1, nmodesx = 256, nmodesy = 256, nprow = 64, npcol = 64. I ran the example program DIIID-helicon with 4096 processors and found some errors（the same error gives only one）:
Abort(469879054) on node 3421 (rank 3421 in comm 0): Fatal error in PMPI_Recv: Message truncated, error stack:
PMPI_Recv(171): MPI_Recv(buf=0x4000740012d0, count=1, dtype=USER, src=53, tag=9976, comm=0x84000001, status=0x177116c0) failed
(unknown)(): Message truncated

The command to submit the job is:
$yhbatch -N 128 -n 4096 -p work ./run.sh
run.sh:
#!/bin/bash
yhrun -N 128 -n 4096 -p work xaorsa2d

-N: The number of nodes required
-n: The total processors
128GB memorry and 56 proceesors / node.

Does anyone know how to solve this problem ? Tks.

Harvey

Ntilda calculation from Fred below:

"From the continuity equation, one would think that ntilda should look like div(Je) which would be noisier than E itself. But in looking at it more closely, I see that Naoto and I did not calculate it by taking numerical derivatives of Je, precisely because it was too noisy. Instead, we got it directly from velocity space integrals of f1 which is linear in E, but has a bunch of sums over Bessel functions and Z functions (Z0, Z1 and Z2) in it. Off hand, I don't see where delta0 enters, but maybe the Z functions are noisy, especially if we str using the new fancy ones. I don't remember what we were doing for the Z functions."

Fred.

There seems to be an inconsistency between how GENRAY and AORSA read equilibria. I am a bit confused about this because AORSA and GENRAY use eqdsk-files, which should have a clearly defined COCOS number; 3 according to this article. The same article states that GENRAY has a COCOS of 5. I could not verify this in the GENRAY documentation, since it is older than the COCOS conventions. Also in the documentation, it does not mention the support for eqdsk-files, so I guess this was added later.

Below you can find a side and top view of GENRAY vs. AORSA with 11 toroidal mode numbers. The virtual antenna is at 186 deg,. and the small white circle is the PCI at 235 deg. Note that when I calculate the toroidal mode numbers from the eqdsk, I get a positive sign, but I used a negative sign in AORSA to get the correct poloidal propagation direction. Also, I shift phi by 186 degrees, when calculating the electric fields in 3D from the AORSA results. This puts the starting point of the beam at the location of the virtual antenna.

@cornwalllau In your COMSOL model, I had to remove the negative sign you added to the magnetic field, and invert the toroidal mode number (i.e. use negative numbers) to get alignment between COMSOL and GENRAY. I also need to add a shift to phi (here 180 degrees which is the actual antenna location).

Does this make sense to any of you? I am at a loss at this point, and unwilling to submit further calculations of AORSA before this is sorted out.
AORSA_GENRAY_top.pdf
AORSA_GENRAY_side.pdf

need to resolve this as I don't want both hanging around.

seems like the makefile.cori and makefile.cori.bh differ in this way

I tried to recompile AORSA, but I get the following error message:

obj/zfun_hilbert_mod.o: in function `zfun_hilbert_mp_zfun_hil_init_':
zfun_hilbert_mod.f90:(.text+0xab4): relocation truncated to fit: R_X86_64_32S against symbol `zfun_hilbert_mp_work_' defined in COMMON section in obj/zfun_hilbert_mod.o
obj/ztable.o: in function `ztable_zfunc_':
ztable.f90:(.text+0x13f): relocation truncated to fit: R_X86_64_32S against symbol `ztable_mod_mp_zfunc_imag_' defined in COMMON section in obj/ztable.o
ztable.f90:(.text+0x19d): relocation truncated to fit: R_X86_64_32S against symbol `ztable_mod_mp_zfunc_real_' defined in COMMON section in obj/ztable.o
ztable.f90:(.text+0x1a7): relocation truncated to fit: R_X86_64_32S against symbol `ztable_mod_mp_zfunc_imag_' defined in COMMON section in obj/ztable.o
ztable.f90:(.text+0x1e1): relocation truncated to fit: R_X86_64_32S against symbol `ztable_mod_mp_zfunc_real_' defined in COMMON section in obj/ztable.o
ztable.f90:(.text+0x1eb): relocation truncated to fit: R_X86_64_32S against symbol `ztable_mod_mp_zfunc_imag_' defined in COMMON section in obj/ztable.o
ztable.f90:(.text+0x1fa): relocation truncated to fit: R_X86_64_32S against symbol `ztable_mod_mp_zfunc_real_' defined in COMMON section in obj/ztable.o
ztable.f90:(.text+0x204): relocation truncated to fit: R_X86_64_32S against symbol `ztable_mod_mp_zfunc_imag_' defined in COMMON section in obj/ztable.o
ztable.f90:(.text+0x217): relocation truncated to fit: R_X86_64_32S against symbol `ztable_mod_mp_zfunc_real_' defined in COMMON section in obj/ztable.o
ztable.f90:(.text+0x4a0): relocation truncated to fit: R_X86_64_32S against symbol `ztable_mod_mp_zfunc_real_' defined in COMMON section in obj/ztable.o
ztable.f90:(.text+0x4aa): additional relocation overflows omitted from the output
make: *** [makefile:163: xaorsa2d] Error 1

This can be fixed by adding -mcmodel=large to the f90flags in the makefile. Note that I did not change anything else so this must be due to some dependency. Maybe some other linked library is hogging all the memory. If you think that this workaround is acceptable I will push the change and create a pull request.

Aside from the automatic testing, has anybody run a regression test of the version that ended up here on github against an earlier version, or would it be worthwhile to do so, for example against the case Cornwall shared with us.
This would of course not be cheap computationally.

It seems that Wdot has regions in which it is negative in the two cases 170325 and 166508 I have run so far. The problem is worse in 170325 than in 166508. This is the spectrum for 170325 and this for 166508. For now, I would like to focus on 170325.

The AORSA input file can be found here. A comparison of the power deposition between GENRAY and AORSA is found here. Note that I used rho_pol as the coordinate system for GENRAY and AORSA, which is unconventional. In future calculations, I will use rho_tor.
Finally you can find a comparison of the AORSA and GENRAY poloidal trajectory [here(https://github.com/ORNL-Fusion/aorsa/files/8411242/AORSA_vs_GENRAY_170325_pol_view.pdf)

Details:

• For all plots of AORSA I use a single toroidal mode number, namely 69 which translates to N_par =3 at the physical antenna.
• For GENRAY I use 7 poloidal rays and N_par slightly larger than 3 to reflect the change in N_par that occurs between the physical antenna and the virtual antenna at LCFS I use in AORSA and GENRAY.
• I double-checked the profiles in GENRAY and AORSA, they are the same as far as I can tell.
• The AORSA calculation for 170325 was already relatively expensive (about 100k CPUh per mode). Increasing the resolution much further is not feasible.

If you require any additional information please ask, and I will provide it. I am also happy to run convergence tests with AORSA. For those I would appreciate your suggestions on how much I should increase the resolution.

Please let me know if you have any ideas...

Hei AORSA experts,
I finally started to work with AORSA in the earnest. I already did one big run in the past but there I had insufficient resolution. I have changed the scenario such that k_perp is smaller.
This AORSA run, however, crashed on CORI. I ran it successfully on my laptop with 16x16 modes to make sure the input is OK.
Only real change that I am aware of is that changed the nmodesx=288 and nmodesy=504 such that they are an integer multiple of my nprow=72 npcol=72.
Input file, batch script and .e file attached. The .o file is empty. I followed the instructions on this page to submit the AORSA run.
Any insights are appreciated.
With kind regards
Severin
P.S. Note that I had to change the extension of the files for github to accept them.
AORSA2D_e33599278.txt
aorsa2d_in.txt
batchscript_cori_full.txt