Skip to content
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

Merged
merged 27 commits into from
Aug 9, 2022

Conversation

boris-martin
Copy link
Contributor

@boris-martin boris-martin commented Apr 10, 2022

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

  • Cleanup of the case file and precice-config
  • Add a run.sh and a cleanup file
  • Validation of the case. (For now: looks good but not exactly similar to other cases. Detailed comparison to do)
  • format Python script (if we keep it ?)

@@ -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.
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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

Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

@MakisH
Copy link
Member

MakisH commented Jul 19, 2022

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 ccx_preCICE -i solid -precice-participant Solid, as a run.sh is not yet available), leads to a configuration error:

---[precice]  This is preCICE version 2.4.0
---[precice]  Revision info: v2.4.0
---[precice]  Build type: Debug
---[precice]  Configuring preCICE with configuration "../precice-config.xml"
---[precice]  I am participant "Solid"
Using quasi 2D-3D coupling
Set ID Found 
---[precice] ERROR:  The given mesh name "Solid-Mesh-nodes" is unknown to preCICE. Please check the mesh definitions in the configuration.

Just check again in a few weeks.

@boris-martin
Copy link
Contributor Author

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)

@boris-martin boris-martin marked this pull request as ready for review July 19, 2022 22:20
@boris-martin
Copy link
Contributor Author

Refactored this to be a new tutorial in a new folder. Big part of the diff is the copy of the fluid-openfoam from the non-CalculiX version of this. I have yet to write a new README, and there's a small issue where CalculiX crashes at the last time window which i'll have to investigate. Otherwise, ready for review.
If you want to run it, make sure you're using the develop branch of the CalculiX adapter.

@boris-martin boris-martin changed the base branch from master to develop July 19, 2022 22:28
@MakisH MakisH self-requested a review July 20, 2022 07:22
@MakisH
Copy link
Member

MakisH commented Jul 20, 2022

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.mp4

Useful 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.

@boris-martin
Copy link
Contributor Author

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.

flow-over-heated-plate-calculix/README.md Outdated Show resolved Hide resolved
flow-over-heated-plate-calculix/README.md Outdated Show resolved Hide resolved
@@ -0,0 +1,53 @@
---
title: Flow over heated plate with two meshes
permalink: tutorials-flow-over-heated-plate-two-meshes.html
Copy link
Member

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).

@MakisH
Copy link
Member

MakisH commented Jul 20, 2022

Thanks for the README! Still open:

  • The strange "double free" error at the end of the CalculiX simulation.
  • Closer look at the results / tuning

boris-martin and others added 2 commits July 20, 2022 23:39
Co-authored-by: Gerasimos Chourdakis <makishourdakis@gmail.com>
@uekerman
Copy link
Member

Let's also add a link from the normal flow-over-heated-plate to this one.

@boris-martin
Copy link
Contributor Author

Let's also add a link from the normal flow-over-heated-plate to this one.

There's already one in the Setup description

@uekerman
Copy link
Member

There's already one in the Setup description

Is there? This PR only touches flow-over-heated-plate-calculix right now, right?

@boris-martin
Copy link
Contributor Author

Oh my bad I misread. There's one in the other direction, but the one you mention is indeed missing.

@boris-martin
Copy link
Contributor Author

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.:

flow-plate-fine

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 :)

@MakisH
Copy link
Member

MakisH commented Jul 26, 2022

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.

This is a known issue we can do little about: precice/openfoam-adapter#26

That's why at the end of every OpenFOAM run.sh, we call the removeObsoleteFolders.

@precice-bot
Copy link
Collaborator

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

@boris-martin
Copy link
Contributor Author

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.
Updated the main README too.

flow-over-heated-two-meshes/README.md Outdated Show resolved Hide resolved
flow-over-heated-two-meshes/README.md Outdated Show resolved Hide resolved
flow-over-heated-two-meshes/README.md Outdated Show resolved Hide resolved
boris-martin and others added 6 commits August 9, 2022 23:05
Co-authored-by: Gerasimos Chourdakis <makishourdakis@gmail.com>
Co-authored-by: Gerasimos Chourdakis <makishourdakis@gmail.com>
Co-authored-by: Gerasimos Chourdakis <makishourdakis@gmail.com>
@boris-martin boris-martin merged commit 9d722d3 into develop Aug 9, 2022
@MakisH
Copy link
Member

MakisH commented Aug 10, 2022

I realize too late that this needs two more fixes:

  • Making OpenFOAM write as frequently as CalculiX did not help and actually made the simulation quite slow. I should have actually thought this a bit longer and suggested to make CalculiX write as infrequently as OpenFOAM. But most importantly, we should probably write in every coupling time. Otherwise, we get inconsistencies between coupling times. But this may also hide a deeper problem.
  • We should make the CalculiX plate as thick as the OpenFOAM channel. Right now, the one is 0.2m thick, and the other 0.5m, leading to strange visuals in paraview.

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.

boris-martin added a commit that referenced this pull request Aug 10, 2022
@MakisH MakisH deleted the flow_heated_plate_calculix branch November 22, 2023 09:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Missing flow-over-heated-plate with CalculiX
4 participants