Addition of sw1.dat values to constBg

[ivanzait]

Modification of sw1.dat file might cause issue. Namely, magnetic field from the sw1.dat will be added on top the constBg creating the artificial discontinuity coming from the inflow boundary.

[ursg]

This is, no doubt, confusing behaviour. Especially when it comes to time-varying inflow. But all of our simulation config files from time eternal have now relied on it. Should we make a breaking change to fix it? Or: Should the code maybe print a big friendly warning if it detects that the BGB from the cfg file matches the value in sw1.dat?

[ivanzait]

My opinion (as of the new user), is that a comment inside of sw1.dat with an explanation of where those values actually go - will be enough

[ursg]

Ah, that's a nice idea actually... since realistically, everybody just takes an existing sw1.dat and modifies it when setting up a new run.

But then we should make sure that we actually put those comments into all of them, systematically.

[ursg]

(In the same step, we can also add an explanatory header that actually, once and for all, documents which number means what. I think I have had to look up their meaning from the source code half a dozen of times in the last years...)

[alhom]

Template-B values will be set from the last Maxwellian inflow population that gets templated: https://github.com/fmihpc/vlasiator/blob/62ac639d96eba005b66ba589bd69c2093663db92/sysboundary/setmaxwellian.cpp#L265

So this is a bit... risky, when we have multiple populations. If we want to stick to the same format, I think it would be better to have IMF defined in its own file instead... but that'd be an extra file to keep track of, which is a bit inelegant (... but better than competing files).

[ivanzait]

(In the same step, we can also add an explanatory header that actually, once and for all, documents which number means what. I think I have had to look up their meaning from the source code half a dozen of times in the last years...)

Yes exactly, it was a bit difficult to clarify the meanings of zeros.

[JonasSuni]

Maybe the logfile should say what the effective IMF (and solar wind) is at the start of the simulation. That way it would be easy to check when starting that the conditions are right.

[ykempf]

Effective IMF is different for every cell if there's a dipole for example. So not very practical. But a (better) explanation is certainly feasible. The help text at the moment says:

  --<population>_maxwellian.file_x+ arg
  Input files for the set Maxwellian inflow parameters on face x+. Data format per line: time (s) density (p/m^3) Temperature (K) Vx Vy Vz (m/s) Bx By Bz (T).

so feel free to send a PR with an amended text. The code lines are here. Something like "the magnetic field components are added to possibly existing background field components, this is not the resulting total field" I guess would do? Feel free to amend from your first-time user perspective! :)

I think the first line of a solar wind dat file can be a comment line starting with #, indeed it was included in the KH sample https://github.com/fmihpc/vlasiator/blob/dev/samples/KHB/mxm.dat, so you could also include that line in every dat file you find in the repo.

[alhom]

I think it is fair for a user to expect the dipole to be shielded in the upstream, so "effective IMF" does make sense (until we start introducing SW turbulence or somesuch).

[ivanzait]

The most intriguing part of it is that sw1.dat should keep some number while some of them - not (if I understood correctly): 0.0 0.5e6 0.5e6 -7.5e5 0.0 0.0 0.0 0.0 0.0 where first number - time, second - density, third - temperature, then triplets for velocity and magnetic field components. A reasonable question: why shall we keep moments non-zero and why they don't mess up with parameters in .config file, while the magnetic field needs to be zero. Please, tell me if I'm wrong regarding the statement about keeping numbers for moments

[ykempf]

This tells the code that at this time, the moments as well as the perturbed magnetic field component in the boundary cells should be these values requested by the user. And the problem at hand now is to make it clear to the user that the Bx, By, Bz listed here are added on top of the background field that is set for the whole box elsewhere. (And it gets a bit more complex with the dipole type 4 which transitions from the dipole to the IMF set in the [Magnetosphere] options, and is partly included in the curl-free background field and partly in the perturbed field to obtain the setup we need. – But it remains so that this B in the input dat file is to be added to whatever is already there from the Magnetosphere or other project setup).

[markusbattarbee]

It would also be possible that magnetospheric project runs would take the input IMF value and instead of placing it in BGB. place it in perB. That would make BGB a pure dipole field (or dipole + mirror dipole). Still, this would also be a breaking change, but would bring magnetospheric runs to be in line with all other projects.

[alhom]

... and ceterum censeo, IMF should not anyway be given by some one-of-n-populations inflow file.