-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add channel-transport transport OpenFOAM #551
base: develop
Are you sure you want to change the base?
Add channel-transport transport OpenFOAM #551
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides the fact that solver and config are in the same directory, it looks good overall. I have not yet tried to run it.
@@ -41,6 +41,8 @@ Transport participant: | |||
|
|||
* Nutils. For more information, have a look at the [Nutils adapter documentation](https://precice.org/adapter-nutils.html). This Nutils solver requires at least Nutils v7.0. | |||
|
|||
* OpenFOAM. This case uses a modified version of scalarTransportFoam, which recomputes `phi` after the preCICE adapter reads the velocity field. Build it with `wmake`. Read more details in the [OpenFOAM adapter](https://precice.org/adapter-openfoam-overview.html). Note that T accumulates in front of the outlet as this case conserves overall T. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* OpenFOAM. This case uses a modified version of scalarTransportFoam, which recomputes `phi` after the preCICE adapter reads the velocity field. Build it with `wmake`. Read more details in the [OpenFOAM adapter](https://precice.org/adapter-openfoam-overview.html). Note that T accumulates in front of the outlet as this case conserves overall T. | |
* OpenFOAM. This case uses a modified version of scalarTransportFoam, which recomputes `phi` after the preCICE adapter reads the velocity field. Build it with `wmake`. Read more details in the [OpenFOAM adapter](https://precice.org/adapter-openfoam-overview.html). Note that `T` accumulates in front of the outlet as this case conserves overall `T`. |
For consistency.
However: is this really intended, or a modelling issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a modelling issue that I couldn't find a solution for. I also ran out of people to ask for help
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should better understand this, and either add details, or fix it. I think right now it just looks wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I start feeling very uneasy that we duplicate this file everywhere.
Opened an issue: #559
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no uniform style in the tutorials repo. I don't see an easy solution for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a .clang-format
file in the root directory: https://github.com/precice/tutorials/blob/develop/.clang-format
Let's discuss in #559.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should have these in the central gitignore: https://github.com/precice/tutorials/blob/develop/.gitignore
The 0/
is already covered, the rest could go there as-is (strange we don't have them already).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the other way around.
0/
is tracked and 0.*/
ignored by default. In my case I generate 0/
from 0.orig/
, which is the exact opposite of what the gitignore defines.
Lines 41 to 43 in 3f253cc
0.*/ | |
[1-9]*/ | |
!0/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interestingly, we don't have a .gitignore
in https://github.com/precice/tutorials/tree/develop/partitioned-pipe-two-phase, which should have the same issue.
But again, the Make/
-related rules can go into the central .gitignore
, or at least moved to the solver directory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain the exact history of this file?
What did you get from where, what did you add yourself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where would you expect to find this information? In the file itself or in a README in the directory of the solver?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just here first, to decide on what to do with this header.
But eventually in the file itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A comment here would be nice.
I assume you are initializing a blob of T
at (1,1).
/*--------------------------------*- C++ -*----------------------------------*\ | ||
| ========= | | | ||
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | ||
| \\ / O peration | Version: v2312 | | ||
| \\ / A nd | Website: www.openfoam.com | | ||
| \\/ M anipulation | | | ||
\*---------------------------------------------------------------------------*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These headers are actually misleading, since we anyway have changed these configuration files a lot compared to what you might have started from.
(referring to this file and the fvSolution
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you suggest me to handle this? (also in the solver source)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am suggesting to remove the copyright header from the fvSchemes
and fvSolution
, because it is wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about the actual solver sources?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There we need it, since it is actually a small extension of OpenFOAM code.
But this is discussed in #551 (comment)
divSchemes | ||
{ | ||
default none; | ||
div(phi,T) Gauss linearUpwind grad(T); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does tuning this maybe help with the strange values at the outlet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to try. I wasn't able to change the behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can eventually try this together, but I don't have the time to debug this at the moment. That's why I am giving a hint on what I think could help first.
This PR adds an OpenFOAM variant of the transport participant of the channel-transport tutorial.
The case uses a modified version of the scalarTransportFoam application. Main difference is that we assume$\phi$ every timestep.
U
to change every timestep. Therefore we need to recomputeNote that this solver conserves the overall
T
, leading to an accumulation of the concentration close to the outlet.@MakisH Can you give this PR a thorough review to make it as easy to use as possible?
Result:
coarse-blob.mp4
Checklist:
changelog-entries/<PRnumber>.md
.