-
-
Notifications
You must be signed in to change notification settings - Fork 109
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
Added CalculiX case for flow-over-heated-plate #271
Conversation
flow-over-heated-plate/README.md
Outdated
@@ -53,6 +53,9 @@ cd solid-fenics | |||
|
|||
in order to use OpenFOAM and FEniCS for this test case. Feel free to try different combinations, they should all run and give approximately similar results. | |||
|
|||
|
|||
Note that to use CalculiX as solid solver, the configuration file `precice-config-calculix.xml` must be used instead of `precice-config.xml`. The CalculiX case is already configured to use it, but the fluid solver must be adapted. Modify the `system/preciceDict` file in the OpenFOAM case to use the correct one. This is necessary because CalculiX use different meshes for the temperature (read at the nodes) and for the heat flux, computed on face centers. |
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.
This is problematic in my opinion. The CalculiX participant should use the same config. We need to bring temperature and heat flux values on the same mesh.
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.
Not sure what's the right approach then. I think we can apply concentrad heat fluxes on nodes instead of faces, but then we'd need a conservative mapping, so here we go again for a new config file. Unless we want to add some dirty hack like "read fluxes on nodes then convert them to CalculiX faces fluxes, with some kind of averaging of a node for a given face"?
That would require a significant upgrade of the adapter but should be doable. Then we'd need to have either fluxes on faces or on nodes for backwards compatibility.
To be sure: do you dislike the fact that we need a different config for a tutorial, or the fact that CalculiX in general has two kinds of meshes? In the first case we could simply have a different tutorial?
Poke @MakisH as we discussed a bit about 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.
To be sure: do you dislike the fact that we need a different config for a tutorial, or the fact that CalculiX in general has two kinds of meshes? In the first case we could simply have a different tutorial?
The first. Yes, last resort would be a different tutorial.
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.
So shall I try to add a mesh conversion inside CalculiX ? I don't think there's a way to keep one config in the current state of the adapter.
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.
This depends on how complicated it would get.
Doable -> let's do it
Complicated and hard to maintain -> better additional tutorial
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'll investigate then. Parts look easy (map from vertices to faces) but other directions should be harder. I'll let you know
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 also think that extending the CalculiX adapter to handle both cases would probably be the most sustainable solution here. We should still inform the user that there is an additional interpolation happening under the hood, though.
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.
Since the easiest right now is to provide an additional tutorial, @boris-martin already moved the case to flow-over-heated-plate-calculix
(and it already runs for me, till the last time step where CalculiX reports something that looks like a "double free" error, as currently known).
The name flow-over-heated-plate-calculix
sounds a bit too specific, though. We do provide it just because of the current state of the CalculiX adapter, but can we find a more generic name? Even flow-over-heated-plate-two-meshes
or something similar.
If we really want to have it as something temporary, then let's keep the -calculix
part and let's document in the README.md
that this is intended as a first step and will be eventually merged.
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.
flow-over-heated-plate-two-meshes
Looks good to me if you think that's a better idea.
Since people are asking about this case, this PR is currently marked as "draft" and it seems to not be ready to run yet. For me, running (with
Just check again in a few weeks. |
It's because the wrong precice-config is used. The precice-config-calculix must be used instead. I'll clean this up and move it to another directory with correct configuration. (Also, up-to-date develop version of the adapter is needed) |
Refactored this to be a new tutorial in a new folder. Big part of the diff is the copy of the |
I ran the case and the results look good, but only after a few iterations (this looks more like a steady-state case). In the beginning, the temperature around the interface is quite off: flow-over-heated-plate-openfoam-calculix.mp4Useful information for the README: here I converted the CalculiX results to VTK using the frd converter bundled in the CalculiX adapter. CalculiX produces 1000 result files, which one can then synchronize with OpenFOAM using the "Temporal Shift Scale" filter, using a scale of 0.01. Since the temperature is named differently in each solver, a "group" filter does not work, but setting the same scale to both (from 300K to 310K) helps. |
I have the same results. I'm a bit surprised we don't get a continuous temperature after a few iterations (since coupling is implicit, I thought it'd be enough). I don't know if it's a bug or if it's due to bad choice of mesh/mapping. |
@@ -0,0 +1,53 @@ | |||
--- | |||
title: Flow over heated plate with two meshes | |||
permalink: tutorials-flow-over-heated-plate-two-meshes.html |
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.
Don't forget to add this to the sidebar on the website (separate PR).
flow-over-heated-plate-calculix/solid-calculix/generate_mesh.py
Outdated
Show resolved
Hide resolved
Thanks for the README! Still open:
|
Co-authored-by: Gerasimos Chourdakis <makishourdakis@gmail.com>
Let's also add a link from the normal |
There's already one in the Setup description |
Is there? This PR only touches |
Oh my bad I misread. There's one in the other direction, but the one you mention is indeed missing. |
I changed the solid mesh to make it much more refined (~same vertex density as the fluid at the interface). If I do that and modify OpenFOAM to have one output every 0.01s (i.e. one per time window), I get something good-looking (using the time shift you recommended, which I'll have to document). Also, I quite increased the implicit coupling accuracy (reduced tolerance, 1e-9 instead of 1e-5.: I had weird things using the original output interval (0.20), like times being [0.19, 0.20, 0.39, 0.40, ...]. @MakisH I need your OpenFOAM expertise to understand that part. In conclusion, I got good results by changing a lot of things, I'll have to isolate the dominant one because I kind of lost track of all these changes. But we're getting there, and the adapters aren't broken :) |
This is a known issue we can do little about: precice/openfoam-adapter#26 That's why at the end of every OpenFOAM |
This pull request has been mentioned on preCICE Forum on Discourse. There might be relevant details there: https://precice.discourse.group/t/installation-problem-with-calculix-2-19-adapter/1124/8 |
I ran again without changing preCICE implicit coupling tolerance and results look satisfying to me. Should be getting ready then. I think the calculix crash at the end was solved in precice/calculix-adapter#102. |
Co-authored-by: Gerasimos Chourdakis <makishourdakis@gmail.com>
Co-authored-by: Gerasimos Chourdakis <makishourdakis@gmail.com>
I realize too late that this needs two more fixes:
The branch still exists, but I think we will not be able to merge the same MR a second time, so maybe open a separate PR. |
This reverts commit 9d722d3.
Context
To showcase the improvements to 2D-3D coupling with CalculiX (precice/calculix-adapter#94, precice/calculix-adapter#92) and the support of hexaedral elements on face meshes (precice/calculix-adapter#91), an new CHT case can be designed with CalculiX. It also improves the list of illustrated cases with heat transfer, as the only CalculiX tutorial here with heat transfer is the heat exchanger, which is very specific (Robin BC's with explicit coupling on a steady-state simulation). This shows how to use DIrichlet-Neumann coupling on transient problems.
Closes #103
Todolist
run.sh
and a cleanup file