You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was using fastPM for generating the ICs for a full N-body code.
However, when I was checking the Pk of the ICs (at z=99) I found some kind of suppression which starts before the k_nyquist, even when "fixing" the initial Pk through the flag "remove_cosmic_variance". I attach a plot of the tests I have done to illustrate this effect.
I run several tests but I always find the same issue, and I was wondering if I am doing something wrong with the input parameter file or what is going on.
In particular, I am interested in generating the ICs with local-pngs, so I tried setting the flags f_nl_type='local' and f_nl=0/100. And the results are consistent with each other (and with the 'gaussian' case setting f_nl_type=none) with very small differences in the Pk, but in all cases the suppression at large ks appear. I also tried to remove the flag "remove_cosmic_variance" but it does not solve this issue. I attach here the parameter file (I had to change it from .lua to .txt for uploading it here) that I have used for these tests.
Then I run 2LPTic with the same exact cosmological and simulation parameters and in this case this effect does not appear.
For computing the all the Pks that I show in the plot, I have used Nbodykit with the same exact configuration ( Nmesh=2048 , resampler='cic' , compensated=True ). I also tried varying those parameters (including the interlacing one) but it does not solve the problem.
I repeated this tests in two clusters that I have access, but the problem is still there.
So, does anyone have an idea of what could be going on?
Hi, @AdriGut10 I used the Gadget4-NGENIC to generate ICs, recently. And I also found the power suppression near the Nyquist frequency when the FFT-grid size used to generate ICs is equal to the number of samples (in your case is 'Npart'). Increasing this value can alleviate this effect. So I guess this could be the potential problem. I don't know the value of the "Nmesh" parameter which you used in 2LPTic. Maybe you can check the value and see whether this is twice the time of "Npart". For fastpm, I'm not very clear about which parameter can control this value in the code. Maybe related to "pm_nc_factor" or/both "change_pm" in your parameter file.
Wish this can help you! Please let me know if this problem has been fixed, thank you~
Hi!
I was using fastPM for generating the ICs for a full N-body code.
However, when I was checking the Pk of the ICs (at z=99) I found some kind of suppression which starts before the k_nyquist, even when "fixing" the initial Pk through the flag "remove_cosmic_variance". I attach a plot of the tests I have done to illustrate this effect.
I run several tests but I always find the same issue, and I was wondering if I am doing something wrong with the input parameter file or what is going on.
In particular, I am interested in generating the ICs with local-pngs, so I tried setting the flags f_nl_type='local' and f_nl=0/100. And the results are consistent with each other (and with the 'gaussian' case setting f_nl_type=none) with very small differences in the Pk, but in all cases the suppression at large ks appear. I also tried to remove the flag "remove_cosmic_variance" but it does not solve this issue. I attach here the parameter file (I had to change it from .lua to .txt for uploading it here) that I have used for these tests.
Then I run 2LPTic with the same exact cosmological and simulation parameters and in this case this effect does not appear.
For computing the all the Pks that I show in the plot, I have used Nbodykit with the same exact configuration ( Nmesh=2048 , resampler='cic' , compensated=True ). I also tried varying those parameters (including the interlacing one) but it does not solve the problem.
I repeated this tests in two clusters that I have access, but the problem is still there.
So, does anyone have an idea of what could be going on?
Thank you for your attention
run_fastpm_test_ics_unit.txt
The text was updated successfully, but these errors were encountered: