Difference between revisions of "ET Workshop 2015/new developments"

From Einstein Toolkit Documentation
Jump to: navigation, search
Line 6: Line 6:
 
##* Ian Hawke mentions the possibility of other workflow management systems that exist and have a wide user base.  
 
##* Ian Hawke mentions the possibility of other workflow management systems that exist and have a wide user base.  
 
##* desire to include management of simulation data  
 
##* desire to include management of simulation data  
 +
## Reproducibility (Ian Hawke)
 
# Performance in optimization and usability
 
# Performance in optimization and usability
 
## AMR, scaling, adaptiveness
 
## AMR, scaling, adaptiveness

Revision as of 07:05, 13 August 2015

  1. Managing and reproducing data
    1. postprocessing
    2. visualization
    3. simulation management, simfactory
      • Ian Hinder describes situation of simfactory2 and work on simfactory3 (Hinder, Wardell, Schnetter).
      • Ian Hawke mentions the possibility of other workflow management systems that exist and have a wide user base.
      • desire to include management of simulation data
    4. Reproducibility (Ian Hawke)
  2. Performance in optimization and usability
    1. AMR, scaling, adaptiveness
    2. * reduce focus on home grown solution for GR only
    3. * discuss benefits of Chombo and GRChombo. Ian Hawke mentions bad experience with these frameworks in relativity.
    4. Usability
      • more examples, better documentation (hypothetical "science with ET", Carpet)
      • scientific programmers
  3. Code correctness
    1. Cactus-aware correctness testing framework. Ideally with set of a simulation and analysis tests, may e much more heavyweight than testsuite.
    2. HPC correctness test
    3. Updating private codes to agree with ET developments
  4. Community practises
    1. backwards compatibility. Strict compatibility hurts usefulness.
    2. Cactus may have been to conservative mainaining compatibility
    3. IF things broke we were not good about announcing this or providing useful error messages at runtime
    4. hard to provide runtime information or code. Need a method to deprecate code and parameters with escalating warnings/errors/aborts as the deprecated feature becomes older.
  5. Physics modules
    1. better interfaces, evolution agnostic analysis, metadata
    2. adopt standards (preferably public ones, or from neighbouring fields)
    3. initial data: provide more? Better documentation for initial data thorns?
    4. GRHydro development:
      • cleanup
      • coordinate
    5. more standards for hydro
      • provide metadata with ID thorns
      • agree on exactly on what is provided
      • now there are multiple hydro codes that are public
  6. ET maintenance
    1. tickets (weekly telecon?)
  7. computer time for infrastructure development in Europe
    • PRACE only gives prepartory access to test on the given machine but not to develop
    • PRACE ony funds big ones, smaller ones through national agencies. (CINECA offers class C allocations for this)
  8. Usability
    1. documentation wanted, not just code but also on how to do things
    2. larger set of gallery examples
    3. lack of complete documentation. Some part are well documented (Cactus flesh) but newer features are mostly undocumented, for example the tags
    4. want some high level documentation
    5. suggestion to also have a correctness checking framework
    6. non-working examples are included in the toolkit. Example parfiles should be commented to make them easier to understand.
    7. higher level "Einstein Toolkit" user guide.