<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Hi Eric;</div><div><br></div><div>Thanks for the document you posted on the spherical benchmarks. This is an excellent starting point. At the bottom of it you asked some questions and I thought I would take a stab at answering them.</div><div><br></div><div><i>1.) Q: Geoid/Topography kernels, do we need to implement them in Aspect?</i></div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>4.) I'll dig up my results/input files for the A1-A9 cases. </div><div><br></div><div>I had another disk crash, so I'm working from a computer I can't see google drive on, so I'm going from memory. We can discuss more at our upcoming telecom.</div><div><br></div><div>Best,</div><div><br></div><div>Scott</div></body></html>