Imaginary value of ne_tilda

[AreWeDreaming]

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.

[cornwalllau]

This is outside my expertise as I never done this. @ntsujii : How did you do this for your thesis? There is a file called naoto_2D, which I always assumed contained this information, but I am not sure.

[AreWeDreaming]

Ok so I looked through the code, and I guess @ntsujii told AORSA to carry out the sum for him. In this case, it uses the complex ntilda_e. Unfortunately, the imaginary part is not written out anywhere, meaning I have to redo all of my calculations.

[ntsujii]

You do not need to redo all your calculations. All the information is in the "fpm" file. You just need to modify and rerun the summation part with the "nphi_sum_only?" option, takes little time with, say, 16x16 processors.

Honestly, I rarely used the summation feature of AORSA. I have my own suite of codes to do summation for different antenna spetra (with coupling of higher nphi somehow accounted for), synthesize pci signal, generate silo file of ntilde and electric field for visit, and so on. These are simple, computationally inexpensive task that is more easier and flexible to do locally than on a cluster.

Not sure if my code is user-friendly, but John has all the copies.

[AreWeDreaming]

I also do all the summing in postprocessing. Which means I have not one, but 11 fpm files. I am not sure how to tell this AORSA. I'll see if I can extract the ntilda from the fpm files myself. Thanks for the hint.

[ntsujii]

We use to specify multiple nphi values in one run, in which case, all nphis are stored in one fpm file. Did the convention change at some point? You cannot use the aorsa summation feature in that case. Anyway, shouldn't be a problem if you do the postprocessing yourself. Everything is contained in fpm, so in fact, this is the only output file you need to keep.

[AreWeDreaming]

My cases are pretty big, so I submit each toroidal mode number separately. This way I can have multiple calculations running separately.
My initial cases where about 50k CPU hours, so the 11 mode numbers I use would be 550k CPU hours, which is harder to fit into a single job at NERSC. Especially with the current debug mode active at NERSC, which limits the number of Haswell cores to below 500, splitting the toroidal mode numbers is the only way to go.

[AreWeDreaming]

Addressed in #36.