Hello all,
As some of you know, I’m trying to prepare for running production models using ASPECT on my university cluster.
I’m seeking general advice on how to perform cluster scaling studies using some of the built in features of the software.
Specifically, I’m interested in lithospheric deformation problems and while I’ve found many of the cookbooks and benchmarks useful for learning the code, I haven’t found very many that are representative of production models I intend to generate. I know it is best to start simple; however, I also seek to understand the impact of adding complexity on model run time and computational efficiency.
My current plan is to start by using the cookbooks that are related to lithospheric deformation (e.g. crustal deformation and continental extension) as well as the benchmark on brittle thrust wedges.
However, I’ve never done scaling and I learned from the tectonics modeling tutorial videos that some of the setups associated with the modeling I intend to do can affect scaling studies quite a bit (i.e. compositional fields, complex rheologies).
Therefore, as I create a modeling plan I’m seeking guidance on the proper steps in the process. My current plan is to modify the cookbooks mentioned previously, looking first at the convergence of mesh resolution, and then performing sensitivity testing on model and solver parameters.
So I guess my question is, does this seem like an appropriate approach or should I start with something even simpler at these nascent stages? I ran into problems in the past trying to run more complex models without performing these preliminary steps so I want to make sure I’m on the right path and not missing critical steps.
Thanks very much,
Stephanie
Stephanie,
I think that – starting with one of the advanced cookbooks and adding complexity – is a good plan. In the end, understanding “scaling”, “run time”, etc boils down to having a sense of what makes problems complicated, what a rule of thumb is for how many degrees of freedom you should shoot for per process (~100,000, maybe 50,000, but probably not much less), and so on. A lot of it is about having experience of the form “I changed this, and that was the result”. That’s not so different from how different features of a model actually affect the structure of the solution, instead of how it affects the run time or scalability.
“Experience” is something that is difficult to teach, one just has to gain it by doing it. So I think starting from one of the cookbooks sounds good. If you find that you run into issue you don’t understand, then back down to something simpler. If you find that you do understand what is happening as you add more complexity, then you’re on the right track. If you find that you’re basically just changing random lines in the input files and source code because you have no idea what you are doing, ask for help!
Best
W.
Hi Stephanie,
Thank you for posting this question to the forum, which is very much of broad interest to the community.
I agree with all the points and recommendations Wolfgang made, and really the best approach is to just start testing how well models scale as a function of different model parameters versus the number of cores. Intuition on this topic will definitely scale with experience 
.
For reference, here is a partial list of model features that can have a large effect on scaling:
- 2D versus 3D geometries
- 3D model dimensions
- Number of material properties (rock types, strain, etc) being tracked with either compositional fields or particles.
- Use of compositional fields versus particles
- Use of AMR
As you start to test what the optimal number of cores to use for different model setups is, I strongly suggest starting with models using only one time step. If the models are nonlinear, you can also reduce the nonlinear solver tolerance to speed things (ex: 1e-4 → 1e-3), while keeping in mind that the model results are not necessarily highly accurate (e.g., the runs are to help assess optimal scaling).
Please also feel free to start a new forum post showing your initial scaling results, which can then use to discuss additional tests. Again, I think this would be of great interest to the broader community.
Thank you again for posting!
John