[CIG-MC] answers to questions….

[Eric Heien]

Hi Scott,

Thanks for responding to my questions on the Google doc.

> 1.)  Q: Geoid/Topography kernels, do we need to implement them in Aspect?
> 
> It would be unfortunate if Aspect can not do these because they address some of the important questions you raised with me initially regarding benchmarking, i.e., how do you know if any of the codes gets the right answer?  The kernels have well known analytic solutions.  Thus you are not doing a code-to-code comparison, you are doing a comparison to a problem that has a known correct answer. These test the Stokes solver without requiring the energy solver, so you can isolate and verify one component of the code.  This can be quite helpful when it comes to isolating differences between codes.  Also, in the bigger picture, many of us use observational data such as geoid and dynamic topography to constrain models, so this will be added to the requested "feature list" to Aspect at some point.  In other words geoid and topography modules will have significant value to the community beyond the benchmark.   That being said, I think we could move forward with the thermal convection problems.  If we find they agree, there would be less pressing need for the kernel solutions.  In the interest of moving forward quickly, i'd say lets try to get the things we can run with both codes without major changes going.

These certainly can (and should) be implemented in Aspect.  My question was more along the lines of “Has anyone actually implemented this yet?”  I believe the answer is no, but if anyone out there has done so please let us know so we can get a copy of your code.

> 2.) You mention the thermochemical problem and I would recommend leaving that one alone right now, especially given the issues with the 2D thermochemical problem.  If we decide we want to do a thermochemical problem we should probably have more discussion about it and design something from the start that everyone is happy with.  

Leaving out the thermochemical problem for now sounds reasonable.

> 3.) Generally in the benchmarks I have been involved with before, we left it up to the user to decide what was "good enough" in terms of the time-variability of the solution, in part because some of us have methods that  quickly iterate directly to steady state solution.   That said,  I can show you that some solutions at low Ra slowly approach the steady state solution with a long rise with a very shallow slope in the time-series plots.  Others look steady for a while then jump into a new configuration.   Ra=1.0e6 of the Blankenbach et al. paper is a good example of this.  Generally I look for things like Nusselt number and Vrms changing in the fifth or sixth decimal place.   

Right, we’ve seen several examples of quasi-steady state behavior that changes suddenly.  For now I think declaring steady state as Nusselt number and Vrms having < 0.001% change between steps sounds reasonable.

> 4.)  I'll dig up my results/input files for the A1-A9 cases.   

Thanks for the configuration files - Rajesh has already started running them with CitcomS.  One thing we noticed is that Citcom was at version 3.0 in 2008, so the results we get with the current version (3.2.0) may be slightly different.  We’ll keep everyone updated through the mailing list and the telecons.

-Eric