You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#401 should solve the problems reported in #398 with the transport solver. However, the reports issued are still wrong, basically computeInjectedProduced() should be rewritten to fix this.
I suggest two changes that would make these things more robust:
Use some kind of source specification object to clearly specify for any injection source its phase, instead of using the somewhat magical 'transport source' convention (negative is total outflow, positive is first phase inflow).
Instead of trying to figure out after the face how much was injected or produced (as the function computeInjectedProduced() does now), which only can be correct for implicit methods, all transport solvers should instead report these numbers themselves.
The text was updated successfully, but these errors were encountered:
all transport solvers should instead report these numbers themselves.
How do you envision that this reporting should take place? Should SimulatorReport be enhanced to contain field/methods to report these numbers into? I am not particularily fond of objects that burst out to cout/cerr from deep within a method.
By report I meant that the solvers should return some object with the required info, so the simulator class can choose to print it, I guess it was a little unclear. I did not intend that solvers should print more to the terminal.
I have not yet given much thought as to whether SimulatorReport would be the right place to put it.
#401 should solve the problems reported in #398 with the transport solver. However, the reports issued are still wrong, basically computeInjectedProduced() should be rewritten to fix this.
I suggest two changes that would make these things more robust:
The text was updated successfully, but these errors were encountered: