Open MartinKarp opened 4 days ago
MartinKarp
commented
4 days ago No, i dont think so, this is kind of prepackaged statistics while adalbertos pr is for extending it with quantities that one as a user may need that are not covered in this one.
I think expanding on his is a natural next step
timfelle
commented
3 days ago No, i dont think so, this is kind of prepackaged statistics while adalbertos pr is for extending it with quantities that one as a user may need that are not covered in this one.
I think expanding on his is a natural next step
Would it not make sense to merge the two functionalities and do the setup from json on which statistics to compute? Not that the two Pr´s should be merged together though.
MartinKarp
commented
2 days ago Im not sure, this one actually generates a lot of fields that are computed additionally, the other one I think is more to sample fields that are available in the simulation. Which differs a bit in the intended use I guess.
I am envisioning something like fluid_stats - for prebaked, common statistics user_stats - for sampling and computing statistics of fields in the simulation user_fields - for parsing expressions and add fields of derived quantities that can be added to the field registry, currently I guess this is easiest done in usercheck as wecannot parse say "u*v" or so and add it to the field registry
Perhaps the nicest though would be to kind of merge user_stats and user_fields in some sense, or as you say simply have one big stats simcomp with all kind of variations
timfelle
commented
2 days ago Im not sure, this one actually generates a lot of fields that are computed additionally, the other one I think is more to sample fields that are available in the simulation. Which differs a bit in the intended use I guess.
I am envisioning something like fluid_stats - for prebaked, common statistics user_stats - for sampling and computing statistics of fields in the simulation user_fields - for parsing expressions and add fields of derived quantities that can be added to the field registry, currently I guess this is easiest done in usercheck as wecannot parse say "u*v" or so and add it to the field registry
Perhaps the nicest though would be to kind of merge user_stats and user_fields in some sense, or as you say simply have one big stats simcomp with all kind of variations
Sure, We would need to ensure we don't allocate a lot of fields that is not needed for all users. So there would be some thinking to do if we want to have some components off and others on.
But sure having some well defined interface for users to inject their own statistics would probably be nice. But since we have the registry then all fields the user could wish to access is always there so I don't think we should have two different interfaces for the user to do statistics.
Draft for simcomp stats. Rather intrusive so would like a second opinion before I remove all the mean flow, statistics and so on from the case.
Makes it so that all stats are saved into the fluid_stats files rather than being split into mean_field and stats. This is a quality of life change.
I am intending to remove mostly everything stats related an moving it into a simcomp and then add input arguments to the simcomp if one only wants say the reynolds stresses or similar. All more advanced postprocessing will then be carried out in python.
Still work in progress, as one can both have the old stats as well as the simcomp in this pr.
Also builds on the 1d average stats branch, so I guess this should go in after.