Log in


Forgot your password?
 
CIG > Community > Documents > CIG GLADE Workshop Townhall Meeting - July 26, 2010
Personal tools

CIG GLADE Workshop Townhall Meeting - July 26, 2010

Notes from the meeting for public review and comment.

Magali Billen and Wolfgang Bangerth hosted meeting.

About 30 people attended.

  1. Review of CIG.
  2. Update on CIG-2.
  3. Overview of plans for CIG.
  4. Software

Comment Points

  1. Why are their so many codes with similar functions i.e., 4 different mantle convection codes?
    • Response: CIG not only maintains an develops software, but also is a repository of knowledge and a distributor of commonly used software.
  2. What can be done about changing the solver (in order to improve efficiency, accuracy run times, speed) in CitcomS? Or is it better to do this is a new code?
    • Discussion: Because it is not clear what the best solver (and element) combination will be, and because it may not be the same for all problems of interest to the community, some experimentation and testing will be needed. This is difficult (time-consuming) to do in CitcomS. However, a new code will be developed in a more modular way and built on libraries which offer many solver and element choices. Therefore, it may be better to address the solver issue in a/ new code.
  3. A user interface is needed to aid new users to some codes in navigating the options and constructing the input files with consistent options (e.g., Gale).
    • Discussion: should include pops-ups with information about each parameter choice; should check consistency of certain choices (e.g., boundary conditions); should allow the user to define geometrical structures only once and attach properties to that structure. In effect, it needs to allows the geodynamicist to set up the problem the way we are use to thinking about geometry an properties and hide the process of turning that into an input file.
    • Response: this seemed to be strongly supported by many people attending.
  4. Neither CitcomS nor Gale have elasticity. Will elasticity be added Gale? Will elasticity be added to any of the newly developed codes?
    • Discussion: Some responses were strongly in support of needing elasticity in codes for certain problems, while others commented that for many problems long term or convection problems, elasticity may play a minor role.
    • Questions: Ask the working groups and science steering committee to asses feasibility and demand for elasticity? How does this affect the overall development of a new codes?
  5. Need to development of good benchmarks in terms of solution (analytic) that also benchmarks for speed, scaling. This should not only be done for standard analytical problems, but also for speed and scaling for more realistic (challenging) problems.
    • Discussion: appeared to general agreement about this, as claims are made about one code or another being faster, but comparisons are not one-to-one. [See Wolfgang Bangerth's explanation below vis-a-vis code testing/comparisons]
  6. Gale was recently sync with available features in Underworld.
    • Discussion: Sync Gale w/Underworld more frequently in the future to avoid repeating this last extended sync and to provide new features to users more regularly.
  7. Will Rhea be the basis of a new mantle convection code?
    • Discussion: [Correction] Rhea is built on the p4est library, and now Deal-II can also use the p4est library as well for computations to a few billion elements, or degrees of freedom. Good way to explore how to make a scalable mantle convection code. However, p4est is currently not open source. There may be other options instead of p4est, but not sure what is known.
  8. Future Developments: CitcomS is nearing the end of the development line, choices were made with its development in the past, which make it difficult to make further major changes.
    • Discussion:
      • Building a new code that is based on a series of libraries, such as PETSc, Deal-II provides more flexibility and functionality for the community.
      • For new codes, people want spherical, global code with free surface, and ability to impose present day topography on the top surface. Pseudo-free surface has been used in the past. With AMR, not difficult to distort initial mesh surface to match observed topography.
      • We have the opportunity to build on knowledge gained from existing and former codes in the development/migration to the new code(s).
      • What functionalities need early on to get the early adopters to use the new code. Need to get some students/research projects driving the science to motivate the code functionality.
Document Actions

Rhea vs deal.II

Posted by Wolfgang Bangerth at Jul 31, 2010 06:34 PM
Just as a small correction: Rhea is not built on deal.II. Rhea is built on the p4est
library which deal.II can now use as well for computations up to a few billion elements
or degrees of freedom. But p4est is not (yet?) Open Source.

Rhea vs deal.II

Posted by Ariel Shoresh at Aug 03, 2010 01:54 PM

Thanks for the correction and clarification!

Benchmarking

Posted by Wolfgang Bangerth at Jul 31, 2010 06:41 PM
At the meeting, we discussed for a while that codes should be benchmarked not only for correctness but also for speed. I personally think that this is actually not very useful:

If you try to compare two codes for speed, then you can only do that if the benchmark lies in the intersection of feature sets, and typically it is the least common denominator. So, for example, if th goal was to compare the speed of CitcomS vs Rhea, the benchmark would need to use a uniformly refined grid. That's not fair to Rhea because per degree of freedom it is certainly going to be slower than a code that uses a uniform grid, but that's immaterial: By using
an adaptive mesh, Rhea can solve the same problem with far fewer unknowns and so can presumably achieve the same accuracy an order of magnitude faster than the uniform mesh code.

While it is interesting to see how fast different codes are on the same benchmark, I think that in practice little of interest can be learned from this sort of comparison because the point of different codes is that they have entirely different goals and feature sets. But by definition, you can't compare for speed different implementations with respect to the features that they differ in :-)