This is perhaps an architectural question, or a question about the philosophy behind the parameter files.
For a run of compute_halo_properties I see messages as:
The following properties were not found in the parameter file, but will be calculated:
(lots of fields)
The following properties were found in the parameter file, but are invalid:
(lots of fields)
But then I land at errors, that terminate execution, as:
The following properties require PartType0/TotalDustMassFractions:
DustMass
HalfMassRadiusDust
"Can't find required dataset PartType0/TotalDustMassFractions in input file(s)!"
The question is: why not automatically skip fields to be computed, if the required information is not there?
The current situation (for me, not knowing what I'm doing) is that I have to keep adding exclusions to the parameter file, until the run actually proceeds. In particular, what I am doing now is slowly "fixing" parameter_files/FLAMINGO.yml to work on a local copy I have of L1000N0900/HYDRO_FIDUCIAL.
I understand this isn't an issue for large production runs, where everything is fixed and big SOAP runs should be stable and reproducible, but for testing/development when there are many smaller runs, possibly with evolving snapshot fields, it seems a less manual approach to specifying/deciding what quantities to compute would be advantageous.
This is perhaps an architectural question, or a question about the philosophy behind the parameter files.
For a run of
compute_halo_propertiesI see messages as:But then I land at errors, that terminate execution, as:
The question is: why not automatically skip fields to be computed, if the required information is not there?
The current situation (for me, not knowing what I'm doing) is that I have to keep adding exclusions to the parameter file, until the run actually proceeds. In particular, what I am doing now is slowly "fixing"
parameter_files/FLAMINGO.ymlto work on a local copy I have ofL1000N0900/HYDRO_FIDUCIAL.I understand this isn't an issue for large production runs, where everything is fixed and big SOAP runs should be stable and reproducible, but for testing/development when there are many smaller runs, possibly with evolving snapshot fields, it seems a less manual approach to specifying/deciding what quantities to compute would be advantageous.