Closed timofeymukha closed 6 months ago
So, how about changing the names to compute for the actual execution (as it is at the moment) and then use "update" for the deferred operators? That might be clearer than having all the "_" methods.
looks good! huge(0.0_rp)
is fine
So, how about changing the names to compute for the actual execution (as it is at the moment) and then use "update" for the deferred operators? That might be clearer than having all the "_" methods.
The is our convention to point out that something is private
, a bit similar to Python. But in this case I think I will also make `compute` private as well to make sure it cannot be called from the outside. My concern with "update" is that it will be somewhat unclear which one is the wrapper and which "the real thing".
So, how about changing the names to compute for the actual execution (as it is at the moment) and then use "update" for the deferred operators? That might be clearer than having all the "_" methods.
The is our convention to point out that something is
private
, a bit similar to Python. But in this case I think I will also make `compute` private as well to make sure it cannot be called from the outside. My concern with "update" is that it will be somewhat unclear which one is the wrapper and which "the real thing".
Hmm, it seems deferred private procedures have some limitations, if one is to believe this.
https://stackoverflow.com/questions/48023393/how-to-design-a-private-overridable-procedure-in-an-abstract-derived-type
It says all the types have to be in the same module. However, prior to reading this, I implemented locally and compiled with compute_
set to private both in the base type and the descendents. Perhaps, compiler dependent? @njansson do you have some wisdom on this?
The is our convention to point out that something is
private
, a bit similar to Python. But in this case I think I will also make `compute` private as well to make sure it cannot be called from the outside. My concern with "update" is that it will be somewhat unclear which one is the wrapper and which "the real thing".
Sure thing, its all a matter of taste. I am just not sure compute is the word i would use for outward facing one. I would say it is "applying" the source term to the bigger system and the internal one "computes" the values of the source term.
The is our convention to point out that something is
private
, a bit similar to Python. But in this case I think I will also make `compute` private as well to make sure it cannot be called from the outside. My concern with "update" is that it will be somewhat unclear which one is the wrapper and which "the real thing".Sure thing, its all a matter of taste. I am just not sure compute is the word i would use for outward facing one. I would say it is "applying" the source term to the bigger system and the internal one "computes" the values of the source term.
The reason for the compute
for the outward-facing one is a bit historical. At some point we had a lot of different names for this kind of routines, like "update", "compute", "apply", etc. And then at some point we said, let's call them all compute
to homogenize things. So, if you open fluid_pnpn_step
, it is sprinkled with stuff that executes %compute
on itself:-). It kind of became the standard name for the "update your stuff once per time-step" routine. Although, admittedly, some update
and apply
are still present as well since no one bothered to take the time to change it.
The is our convention to point out that something is
private
, a bit similar to Python. But in this case I think I will also make `compute` private as well to make sure it cannot be called from the outside. My concern with "update" is that it will be somewhat unclear which one is the wrapper and which "the real thing".Sure thing, its all a matter of taste. I am just not sure compute is the word i would use for outward facing one. I would say it is "applying" the source term to the bigger system and the internal one "computes" the values of the source term.
The reason for the
compute
for the outward-facing one is a bit historical. At some point we had a lot of different names for this kind of routines, like "update", "compute", "apply", etc. And then at some point we said, let's call them allcompute
to homogenize things. So, if you openfluid_pnpn_step
, it is sprinkled with stuff that executes%compute
on itself:-). It kind of became the standard name for the "update your stuff once per time-step" routine. Although, admittedly, someupdate
andapply
are still present as well since no one bothered to take the time to change it.
Yea it always ends up that way when the system becomes big enough. Good names for things are hard, I always rename things 10-15 times as i develop them... Often it is also just a question of having good enough documentation of what does what and then it will be fine.
start_time
andend_time
json parameters for source terms, so as to limit the execution of the source term in time whe necessary.ifs
you need right in your user source code.source_term_t
is changed to have the new parameters (descendents have to parse the start_time and endtime from the json now before sending them to the base type constructor). The deferred routine is now called `compute, whereas
compute` wraps that with the check on the current time and the user-selected time start and end time. This is exactly the same structure as in the simcomps.compute_
for other purposes, that routine is now renamed tocompute_vector_
huge(0.0_rp)
by default. Is this fine to use, @njansson?