Explaining StGermain: An aspect oriented environment for building extensible computational mechanics...

Steve Quenette, Head of CSD / Senior Software Engineer

Explaining StGermain: An aspect oriented environment for building extensible computational mechanics modeling software

HIPS-TOPMoDRS workshop – IPDPS 2007

Steve Quenette


Outline

… for those interested in large-scale HPC

software…

• Drivers

• Approach

• Technology itself

… for those whose interests are closer to

hardware…


A picture of an outcome

What makes this phenomena model hard to implement?


And another

What’s different here? Why is the “difference” hard?


And some more

Different phenomena: different numerics and physics


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


Lesson learnt with Snark• 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 schemes and physics models render code that cross both controlling and data aspects

• And, statically typed object orientation does not handle this well

typedef struct {double x;double y;int mat_I;

} Particle;

void ConstitutiveUpdate( … ) {…

}

plasticity model:- history dependant slip dir- behaves according to …

typedef struct {double x;double y;int mat_I;double slipDir[3];

} Particle;

void ConstitutiveUpdate( … ) {…if( material == plastic ) {

…}…

}


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


Competencies of a comp. mech. code

Better encapsulation of concerns at each level


StGermain to Underworld

Software layers approximating roles


What does StGermain do?


Input Files & Dictionaries• Your code “pulls” parameters

• StGermain assembles components

Dictionary_GetBool_WithDefault(self.dictionary,“eta0”,1.0f );

main() { … Stg_Component_Construct(

context,…,false

…

)

Dictionary


Components and Variables• 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


Entrypoints & extensions• For real problems: cross cutting issue

… MyPlasticity_ConstitutiveUpdate {…

}

EntryPoint_AppendHook( Context_GetEntryPoint( cnxt, EP_CONSTITUTIVEUPDATE ), MyPlasticity_ConstitutiveUpdate );

ExtensionManager_Add( particleExtMgr,MYPLASTICITY_HANDLE, sizeof(double)*3 );


Conclusion• 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

Explaining StGermain: An aspect oriented environment for building extensible computational mechanics...

Documents

Transcript of Explaining StGermain: An aspect oriented environment for building extensible computational mechanics...