Open uekerman opened 3 years ago
Let me first state the obvious downsides of such a feature:
Wouldn't it be easier to refactor the code by breaking it up into general, precice-on and precice-off chunks?
Then you use precice_used
to select between these chunks in the background.
This can also be done with a class hierarchy.
I see the points. I really meant it for very short codes, such as https://github.com/precice/tutorials/blob/master/flow-over-heated-plate/solid-nutils/solid.py Here, a class hierarchy or if-else code blocks would make things more complicated and less readable.
This prevents us from polluting compact codes
I can provide another example of such polluting code here. In this code I have a single python script to do the single-physics as well as coupled simulation. This is a relatively small code and adding if-else
blocks does not look too bad to me. I would vote against implementing this feature in the bindings as this would make the bindings unnecessarily complicated. changed my opinion on this, really like the idea Benjamin Rodenberg has suggested below, it would be indeed helpful.
We could have a precice_noop
and just do
import precice_noop as precice
this would keep the python bindings clean and it still handles your use case.
Not sure whether I would provide this under precice/python-bindings
or just as an independent package. Most users probably don't need it and this would keep everything independent.
I just found this issue now. I would mostly agree with with @fsimonis and if necessary, I would prefer the approach of @BenjaminRodenberg with precice_noop
.
At the moment I would have the following, additional critical remarks:
noop
option in preCICE. In this case one does not have to implement this in any adapter nor in the bindings. noop
feature for all bindings and adapters, instead of only in preCICE, will potentially lead to a lot of additional code and thus additional places for bugs.Another code example why this feature is needed
Another code example why this feature is needed
Can you elaborate or point to a more specific place? Looking at the code I don't directly see the reason (I only looked very quickly and carelessly, though).
Can you elaborate or point to a more specific place? Looking at the code I don't directly see the reason (I only looked very quickly and carelessly, though).
Sure, if you search if coupling
in the code, you will find five instances where the program flow is disturbed because the intention is to have one single code for single-physics and coupled-physics. The reason for having a single code is mainly software maintainability, i.e. whatever physics is tested in single-physics can be directly used in the coupled case. The code currently is very basic and involves serial-explicit coupling, I can predict that the workflow will get even more complicated when implicit coupling is implemented.
Oftentimes, you want to run a coupled code in single-physics mode, so without preCICE. For codes like OpenFOAM or FEniCS, we would handle this in the adapter. As the Python bindings are also used in codes without adapters (e.g. Nutils) and the codes don't need compiling (Python), it would be really great if there was a simple "switch off" mechanism.
Say
Then all preCICE calls should be NOPs. This prevents us from polluting compact codes with a lot of
Is there a standard Python way how to do this? If not, could we handle it in the Python bindings?
I don't think we need this feature for other bindings as there we have longer codes and/or adapters and we compile. Do you agree?