-
-
Notifications
You must be signed in to change notification settings - Fork 132
Growing mesh case #600
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
Growing mesh case #600
Conversation
@MakisH
MakisH
left a comment
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 know that this is still a draft, but I had a quick look anyway, so I left some comments that I know are probably already on your list.
growing-mesh/README.md
Outdated
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 so far avoid calling participants and data generic names, but try to relate to a specific physical domain and application use case. This is currently only partially described in the naming conventions.
Of course, this is fine for now (and fine for an integration test), but before merging, we should better have more descriptive names.
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.
They both represent the same mesh and don't model any physical behaviour.
Not sure what we would name them.
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 physical motivation for this scenario. We could borrow names there?
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.
The pyhsical motivation is to couple a hydrogeological and geomechanical model and let them iterate until they agree on effective stress.
Without the iterative scheme, there is no correction and the geomechanical model doesn't have a function.
So, I cannot see obvious names that we can use here.
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.
But then we need to better express the motivation in the description and say that the modeling is (extremely) simplified, as is the case in general in our tutorials.
With the current formulation, it is a great integration test, but it looks a bit odd as a 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 added the motivation and more details about the solver.
e322653 to
4ea4cd4
Compare
4ea4cd4 to
dcbe41c
Compare
48f2c5c to
c7dd907
Compare
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 few more minor changes. The case starts, I have not run it beyond Compute consistent mapping yet.
I directly edited the run scripts for consistency.
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.
Could we give a more descriptive name?
Not necessary, but If a user were to install this outside the venv, a growing binary lying around would be quite strange.
One direction could be growing-mesh-solver-python.
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.
Do we need the title case (with PreCICE) here? 😬
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.
The original was a bit difficult for me to read, maybe this is better:
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 and B" are mentioned below, but not introduced. Compromise:
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 post-processing section would be nice, hinting to what the user should see in the end. Note that there is no other figure (besides the config visualization) in this tutorial. Someone that does not yet know what "growing mesh" means would need to read and imagine a bit first, before being able to get a first overview.
An image with the mesh in two different times (potentially with partitions shown) would be helpful.
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 this case even produce any results to show how the mesh grows?
growing-mesh/solver-python/solver.py
Outdated
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 fixed the formatting of these strings (here and in line 58). Cross-check.
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, while the solver messages show up in the correct order when running with two ranks, they show up separately at the end when running serially:
--[precice] time-window 11 (max: 12), t 10, Dt 1, max-dt 1
---[precice] Time window completed
---[precice] Mapping "Data-B" for t=11 from "B-Mesh" to "A-Mesh"
---[precice] time-window 12 (max: 12), t 11, Dt 1, max-dt 1
---[precice] Reinitializing Participant
---[precice] Close distributed communication channels
---[precice] Setting up primary communication to coupling partner/s
---[precice] Primary ranks are connected
---[precice] Setting up preliminary secondary communication to coupling partner/s
---[precice] Prepare partition for mesh A-Mesh
---[precice] Gather mesh A-Mesh
---[precice] Send global mesh A-Mesh
---[precice] Receive global mesh B-Mesh
---[precice] Setting up secondary communication to coupling partner/s
---[precice] Secondary ranks are connected
---[precice] Time window completed
---[precice] Computing "nearest-neighbor" mapping from mesh "B-Mesh" to mesh "A-Mesh" in "read" direction.
---[precice] Mapping distance min:0 max:0 avg: 0 var: 0 cnt: 2621440
---[precice] Mapping "Data-B" for t=12 from "B-Mesh" to "A-Mesh"
---[precice] Reached end at: final time-window: 12, final time: 12
---[precice] Implicitly finalizing in destructor
---[precice] Close communication channels
Rank 0/1 has partition (0, 0)/(1, 1)
Each of 1 partitions has node size 512x512 = 262144 for a total of 262144 nodes on the base
A: data: 0.0 * 524288
A: data: 1.0 * 524288
A: data: 2.0 * 524288
A: Event grows local mesh from 524288 to 1048576 and global mesh from 524288 to 1048576
A: data: 3.0 * 1048576
A: data: 4.0 * 1048576
A: data: 5.0 * 1048576
A: Event grows local mesh from 1048576 to 1572864 and global mesh from 1048576 to 1572864
A: data: 6.0 * 1572864
A: data: 7.0 * 1572864
A: data: 8.0 * 1572864
A: Event grows local mesh from 1572864 to 2097152 and global mesh from 1572864 to 2097152
A: data: 9.0 * 2097152
A: data: 10.0 * 2097152
A: data: 11.0 * 2097152
A: Event grows local mesh from 2097152 to 2621440 and global mesh from 2097152 to 2621440
Uh oh!
There was an error while loading. Please reload this page.
This PR adds a growing mesh case.
Two solvers define the same mesh, which grows at given points in time.
Inspiration for this case is the formation of additional residue layers on the floor of an ocean over time.
@MakisH is this how you envision the separate solver folder to work?
Checklist:
changelog-entries/<PRnumber>.md.