When making a copy of simulation, using the same geometry, meshing will ignore MRF rotation zone definition.
Here are steps to reproduce it in my public project:
Project Fan24Blades > Simulation TriBladeSep > do ‘Duplicate’
In new Simulation Select Mesh > Create new mesh > Confirm (it will clean the meshing setup)
Now in that Selected mesh > Copy New Mesh settings from TriBladeSep > select MeshForTriBladeSep
Result: if you Generate new mesh with identical setting (to MeshForTriBladeSep), MRF zone definition will be ignored. I tried it twice and last result is in simulation ‘TriBladeSepInf2’.
I stumbled upon it when trying to add Inflation zone to well defined mesh. I look now for explanation and help from support.
Recreating the mesh without using copy does not create mesh for MRF rotating zone. Example is ‘TriBladeSepFresh’ simulation, where I did copy the simulation and started new mesh (Mesh 28) filling all parameters by hand.
Possible conclusion: meshing process itself was updated in mean time (last few days) and has different priorities.
Is there a step-by-step instruction that you can provide us with on how to reproduce this or is it just “copy & mesh” to get this kind of behavior? Curious about that. If it is reproducible I will report it.
Step by step guide is in my first post here, on the top of the thread.
By the way: can we have a list of implemented fixes (what, why, when), up to date, please? This would help us to hint about possible culprit of SimScale misbehaviour. Currently it is 100% opaque, I can only muse that fix came from OpenFOAM. Or not, if you did branch sources and develop on your own.
Just to add to this, I am also having the same problem with duplicated meshes not producing the MRF zones. I agree with @Retsam , that it would be extremely helpful, to provide some kind of message when new updates are made, or problems such as this are found, so that users can know if meshes or simulations will not run properly. This would cut down on frustration, and wasted core hours.
First of all - I’m very sorry for all the problems you had. Thanks for reporting it so quickly!
I wanted to chime in and give an answer to @Retsam’s question how the bug came about in the first place.
Some time ago we found that we were showing an option in the cell zone UI which didn’t make sense. Here’s a picture of how it used to be:
We decided to remove the options “insidepoint” and “outside” because they didn’t provide any value but rather added confusion and caused errors sometimes.
The corresponding changes had to be done in 2 different services and one of them wasn’t updated accordingly. The result was that the “new style” cell zones weren’t recognized properly anymore and so they wouldn’t appear for you guys anymore.
This problem shouldn’t have occurred in the first place. Unfortunately our automated tests didn’t catch this. Moving forward we’re going look for a way to test this particular type of bug and add more automated tests around cell zones to make sure they don’t break in this particular way anymore.
