-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial condition doesn't cleanly initialise unstable mode. #34
Comments
Tagging the relevant code sections here: REAL(num), PARAMETER :: v_drift = 0.2_num * c
REAL(num), PARAMETER :: v_therm = 0.01_num * c
REAL(num), PARAMETER :: v_pert = 0.1_num * v_therm
...
DO ix = 1-ng, nx+ng
current_species%drift(ix,:,:,1) = gamma_drift * m0 &
* (v_drift + v_pert * SIN(3.0_num * x(ix)))
END DO Not sure if (1) there's an error in the above code, or (2) the perturbation is too small (I believe it matches that described in Lapenta 2017) or (3) a density perturbation is need as well/would work better. |
Looks like the perturbation is the same sign in velocity for each species: I think it should be the opposite sign to make phase space whorls? |
I think that's a very sensible suggestion. So much so I've already started testing it. |
Doesn't seem to have done anything to fix the differences between different core counts, which I think is a good test for this. |
Results of the equivalent input in EPOCH (1d) |
What's the variation like with core count in EPOCH? |
Haven't tried yet, but since it doesn't seem to be initialising the unstable mode, doubt it is very robust... |
Deck for last case. About 50 second runtime. |
The standard testcase is a two-stream instability, which should be cleanly initialised by a simple sinusoidal density or velocity perturbation, but it seem like these runs are very sensitive to numerical parameters, as if they were starting from numerical noise.
The text was updated successfully, but these errors were encountered: