150 likes | 258 Views
Explaining StGermain: An aspect oriented environment for building extensible computational mechanics modeling software. HIPS-TOPMoDRS workshop – IPDPS 2007 Steve Quenette. … for those interested in large-scale HPC software… Drivers Approach Technology itself.
E N D
Explaining StGermain: An aspect oriented environment for building extensible computational mechanics modeling software HIPS-TOPMoDRS workshop – IPDPS 2007 Steve Quenette Steve Quenette, Head of CSD / Senior Software Engineer
… for those interested in large-scale HPC software… Drivers Approach Technology itself … for those whose interests are closer to hardware… Outline Steve Quenette, Head of CSD / Senior Software Engineer
A picture of an outcome What makes this phenomena model hard to implement? Steve Quenette, Head of CSD / Senior Software Engineer
And another What’s different here? Why is the “difference” hard? Steve Quenette, Head of CSD / Senior Software Engineer
And some more Different phenomena: different numerics and physics Steve Quenette, Head of CSD / Senior Software Engineer
Case-study: the path to Underworld • Convect 1989, 2D, FE/FD, C, Stokes • CITCOM 1994, 3D, FE, MG, FW, Stokes & Greens • CitcomT 1997, 3D-spherical, zero-width-elements • Citcom-w-faults 1997, sub-surfaces • CitcomS 1997, 3D-spherical, better MG, parallel • CITCOM 1997, better MG, better physics • Ellipsis 1998, back to 2D, PIC • Ellipsis-3D 2005, 3D • Snark 2003, parallel, no MG, better FW • Underworld 2006, MG, plasticity, better FW Steve Quenette, Head of CSD / Senior Software Engineer
Snark: our first involvement Observation: new features needed to insert themselves within existing other features New features needed to extend existing other data structures Numerical schemesand physics modelsrender code that cross both controlling and data aspects And, statically typed object orientation does not handle this well Lesson learnt with Snark typedef struct { double x; double y; int mat_I; double slipDir[3]; } Particle; void ConstitutiveUpdate( … ) { … if( material == plastic ) { … } … } typedef struct { double x; double y; int mat_I; } Particle; void ConstitutiveUpdate( … ) { … } plasticity model: - history dependant slip dir - behaves according to … Steve Quenette, Head of CSD / Senior Software Engineer
Approach • The spectrum of laptop to HPC • Parallelisation and portability • Aim: the ability to change a numerical scheme or physics model without needing to change the phenomena model code • phenomena model code becomes our “OO design” • Realization that this is about people with different roles and expectations working together Steve Quenette, Head of CSD / Senior Software Engineer
Competencies of a comp. mech. code Better encapsulation of concerns at each level Steve Quenette, Head of CSD / Senior Software Engineer
StGermain to Underworld Software layers approximating roles Steve Quenette, Head of CSD / Senior Software Engineer
What does StGermain do? Steve Quenette, Head of CSD / Senior Software Engineer
Input Files & Dictionaries • Your code “pulls” parameters • StGermain assembles components Dictionary_GetBool_WithDefault( self.dictionary, “eta0”, 1.0f ); Dictionary main() { … Stg_Component_Construct( context, …, false … ) Steve Quenette, Head of CSD / Senior Software Engineer
Components “Light weight” Have fixed services Source code has a meta file with validation information Variables Cross component associations of data without source code Allows totally declarative creation of state storage Components and Variables Steve Quenette, Head of CSD / Senior Software Engineer
Entrypoints & extensions • For real problems: cross cutting issue ExtensionManager_Add( particleExtMgr, MYPLASTICITY_HANDLE, sizeof(double)*3 ); … MyPlasticity_ConstitutiveUpdate { … } EntryPoint_AppendHook( Context_GetEntryPoint( cnxt, EP_CONSTITUTIVEUPDATE ), MyPlasticity_ConstitutiveUpdate ); Steve Quenette, Head of CSD / Senior Software Engineer
Took a punt with a different approach to large scale HPC software design Usage of aspect concepts in a HPC setting People are coming on board because of the continuous evolution in numerics and physics capabilities Acknowledgements: CSD crew: Pat Sunter, Luke Hodkinson, Alan Lo, Raquibul Hassan, Kathleen Humble, John Spencer Louis Moresi’s group Dave May, Dave Stegman, Vincent Meriaux, Cecile Duboz, Julian Giodani, Rob Turnbull CIG Mike Gurnis, Walter Laundry Conclusion Steve Quenette, Head of CSD / Senior Software Engineer