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

time dependent world builder output #779

Open
8 tasks
MFraters opened this issue Jan 18, 2025 · 0 comments
Open
8 tasks

time dependent world builder output #779

MFraters opened this issue Jan 18, 2025 · 0 comments
Labels
hackathon-2025 a hackathon 2025 project

Comments

@MFraters
Copy link
Member

@alanjyu is interested in a case where he wants to move world builder features over time, to use as a temporary variable boundary condition in ASPECT (and GOLEM?). I remember there being conversations with other people, where there was also interest in similar functionality (for example a continent arriving from outside the model area or a plume coming through the bottom of a model) and I may also have some use for it. So now the question is how to best implement it. One advantage we now have is the velocity system inside of the GWB, which would enable this. I see three options for the interface:

  1. We put an extra variable in the interface which can specify time. The world builder would then for every request, where time is not equal to zero advect everything it need to advect and use that state.
  2. We add a function to advect the word for a specified number of timesteps.
  3. We add a function to advect the world for a specified number of timesteps and return this as new world.

I do not think option 2 is a good idea, because the world would become mutable, which opens a host of problem with multi-threading.

Option 1 and 3 are I think both good options, but I currently have a preference for option 3, since the time computation can all be done at once, instead for every call. Furthermore, all current interfaces can remain the way they are and this would also allow the calling program to do a diff between the old and new world if it wants to.

To get started with option 3, I think the following things need to happen:

  • First, create a function called advect_world or something similar, which takes as arguments the timestep size and the nubmer of timestep. This function would:
  • 1. make a copy of the current world
  • 2. loop trough all the features and their surface points, get the velocity at those locations.
  • 3. Implement a advection scheme (rk4?) and make sure it is acurate enough in both cartesian and spherical coordinate systems.
  • 4. Advect the surface points

Once this works it should already work for the simple cases in which @alanjyu is interested, but we can start thinking about more complicated cases. To accomedate these, we would need to create an interface for all plugins to also allow them to update their internal information based on the timestep, if needed. For example:

  • a rising plume feature would move up (using the prescribed velocity field.
  • A slab would subduct more material based on the distance change between the ridge and trench in that timestep (which we have functionality for now)
  • A oceanic plate feature pushing against a passive margin growing on that side (this might be hard to do well)

I have to note that the goal of this is not to get an advanced kinematic model which could deal with colliding continents and adjusting velocties based on that (although that would be cool), but allow for some relatively simple and straightforward time dependent cases for use as boundary conditions for example.

@MFraters MFraters added the hackathon-2025 a hackathon 2025 project label Jan 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hackathon-2025 a hackathon 2025 project
Projects
None yet
Development

No branches or pull requests

1 participant