Allowing non-uniform vtk time sampling
Closed this issue · 6 comments
Question
Hello there,
What would you think about such an option? Personally I would be very interested in it so I was wondering if you ever considered that, if it would present any difficulty and if you would be ready to incorporate such an option in the main branch if I coded it in the coming weeks.
Hi @jeankpf, can you describe the kind of application you have in mind ?
I expect the difficult part would be to design the new interface so it stays backward compatible, but it can certainly be done !
Another point to keep in mind is that, to keep the interface simple and predictable, such a feature would need to be implemented for all output types, not just vtks.
Thanks for the reply. So in the context of studies of linear instabilities up to a state of saturated turbulence, quantities can vary very quickly during the phase of linear growth, with a characteristic timescale faster than the timescale of turbulence at saturation. So I would like to be able to sample my vtk outputs with a smaller time step at the beginning of the simulation. For instance, with a simulation having tstop=100., I had in mind something like: vtk 0.0 0.1 10.0 1.0 100.0.
We could stay backward compatible by simply analysing the number of elements in the input line of the vtk line, and applying a uniform vtk sampling when this number equals one.
So what you want is a set of fixed times at which outputs should happen ?
What would happen when tstop exceeds the last fixed time ?
One issue with the interface you're proposing is that there's no way to specify a single output time (without breaking backward compatibility), except, I guess, if that time is to be 0 (and even then I'm not sure you wouldn't get divide-by-zero errors).
Yes I would like to be able to specify different time intervals (in code units) with different (but given) time steps. My way of seeing the case tstop > last fixed time would be not to produce any vtk output for times between the last fixed time and tstop. The only way I see to include this option without breaking backward compatibility would be to implicitly assume that, when only one number is given in the vtk line of the initialisation file, then it needs to be understood as the time step to be used to uniformly sample vtk outputs during the whole simulation. But this requires indeed an implicit assumption that may not be the way the initialisation file is currently thought.
While I do understand what you have in mind and the proposed implementation @jeankpf , I have a hard time justifying the burden of adding (and maintaining!) this layer of complexity.
The reason is the only case where you'd do what you suggest is when you know well in advance when saturation will occur. But even then, I would say that keeping a spacing of the vtk files every e-folding time or so should be enough (unless growth is super-exponential ?)
If the idea is to reduce the frequency of vtk outputs once saturation has been reached, then you can already do that. Just change the vtk frequency in your input file and restart. At least, you will not loose any output if t exceeds the largest output time you have added.
The problem I have is that in principle, one should implement this procedure for every output format we support (and new ones are coming). Hence, we should probably start to think about a master output class that would encapsulate this procedure from which every file format would inherit. Another issue is what happened if dt exceeds the spacing between 2 given output times? Do we keep them all? Do we skip some ? And as @neutrinoceros mentioned, what do we do if tstop exceeds the largest vtk time step? A warning when we reach it? Should we stop? A Warning at the beginning ? Nothing? But then, computational ressources will certainly be lost by some users who did not think that the code would keep running without producing any output.
It's fine to implement that in your own fork, but having this included in the public master is not as straightforward as it seems from my point of view.
Yes sure I understand the (unforeseen, on my side at least) difficulties associated to the development of such an option. The solution you proposed with restarting to by-pass it is indeed what I should (and probably will) do in the future, but from the viewpoint of a user, it looked a bit like an overkilled solution to me and that's why I proposed this implementation. But I do also understand the burden it might represent from a developper point of view.