GENIE BFG - Revision history

Genie-user: /* Scheduling */

2008-08-26T11:08:59Z

Scheduling

Genie-user: /* Scheduling */

2008-08-26T11:04:28Z

Scheduling

Genie-user: /* Scheduling */

2008-08-26T11:01:35Z

Scheduling

Genie-user at 17:42, 26 February 2007

2007-02-26T17:42:46Z

Genie-user: /* See also */

2007-02-26T17:25:23Z

Genie-user: /* GENIE framework generation */

2007-02-26T17:25:01Z

GENIE framework generation

Genie-user: /* Coupling with PRISM */

2007-02-26T17:24:31Z

Coupling with PRISM

Genie-user: /* External links */

2007-02-26T17:00:31Z

External links

Genie-user: GENIE:BFG moved to GENIE BFG

2007-02-26T16:59:04Z

GENIE:BFG moved to GENIE BFG

Genie-user: /* See also */

2007-02-22T13:12:09Z

@@ Line 172: / Line 172: @@
 The BFG metadata can also be used to describe the structure of more complex control code, e.g. for argument passing models like GENIE.  BFG scheduling data is able to represent control code with inner loops or convergence based loops, and model timesteps are specified in the model definition data.  (A model may run at a different timestep to the overall framework timestep and the timesteps of other models.)  An example of such control code is shown in Figure 4.
-{|border="2" cellspacing="0" cellpadding="4" width="61%" align="center"
+<pre>
 !Main model framework timestep loop
- ! Main model framework timestep loop
+For Each timestep
- For Each timestep
+  Call M1( args )
-   Call M1( args )
+  !Different timestep
-   ! Different timestep
+  If ( timestep Mod 2 ) Then
-   If ( timestep Mod 2 ) Then
+    Call M2( args )
-     Call M2( args )
+  End If
-   End If
+  !Inner loop
-   ! Inner loop
+  For i = 1 To 5
-   For i = 1 To 5
+    Call M3( args )
-     Call M3( args )
+  End For
-   End For
+End For</pre>
 <center>

@@ Line 172: / Line 172: @@
 The BFG metadata can also be used to describe the structure of more complex control code, e.g. for argument passing models like GENIE.  BFG scheduling data is able to represent control code with inner loops or convergence based loops, and model timesteps are specified in the model definition data.  (A model may run at a different timestep to the overall framework timestep and the timesteps of other models.)  An example of such control code is shown in Figure 4.
   ! Main model framework timestep loop
   For Each timestep
@@ Line 186: / Line 188: @@
     End For
   End For
 <center>

@@ Line 171: / Line 171: @@
 The BFG metadata can also be used to describe the structure of more complex control code, e.g. for argument passing models like GENIE.  BFG scheduling data is able to represent control code with inner loops or convergence based loops, and model timesteps are specified in the model definition data.  (A model may run at a different timestep to the overall framework timestep and the timesteps of other models.)  An example of such control code is shown in Figure 4.
   ! Main model framework timestep loop
   For Each timestep

@@ Line 80: / Line 80: @@
 ===Definition===
-'''''[[GENIE:BFG files#Example Definition file|Example Definition file]]'''''
+'''''[[GENIE_BFG_Files#Example Definition file|Example Definition file]]'''''
 BFG definition data is associated with each model within a framework.  The definition data describes the interface to the model.  The interface may either consist of entry point subroutines and their arguments (an argument-passing, or "argpass" interface), or ''put'' and ''get'' calls embedded in the model source code (an "inplace" interface), or a mixture of the two.  Entry point subroutines comprise:
@@ Line 96: / Line 96: @@
 ===Composition===
-'''''[[GENIE:BFG files#Example Composition file|Example Composition file]]'''''
+'''''[[GENIE_BFG_Files#Example Composition file|Example Composition file]]'''''
 BFG composition data describes how fields are connected between models.  This is done in two different ways for "argpass" and "inplace" I/O.
@@ Line 106: / Line 106: @@
 ===="Argpass" I/O====
-For argpass I/O (passing of fields through timestepping subroutines), set notation is used in the composition data to describe how arguments are connected across different models.  Since the order entry point subroutines are called in affects how fields are connected across models, it was considered simpler to use set notation (rather than point-to-point) for argpass I/O - connections between fields are made by grouping together the subroutines that use a particular field, with no reference to where the arguments come from, as this is determined by the order they are called in according to the deployment data - see [[GENIE:BFG#Scheduling|Scheduling]].  Figure 1 shows a set for coupling field "arg1":
+For argpass I/O (passing of fields through timestepping subroutines), set notation is used in the composition data to describe how arguments are connected across different models.  Since the order entry point subroutines are called in affects how fields are connected across models, it was considered simpler to use set notation (rather than point-to-point) for argpass I/O - connections between fields are made by grouping together the subroutines that use a particular field, with no reference to where the arguments come from, as this is determined by the order they are called in according to the deployment data - see [[GENIE_BFG#Scheduling|Scheduling]].  Figure 1 shows a set for coupling field "arg1":
 [[Image:Introduction_to_BFG_Figure_1.png|center]]
@@ Line 114: / Line 114: @@
 </center>
-BFG is able to work out whether arg1 is input or output from each model by analysing the definition data for that model.  Coupled with the [[GENIE:BFG#Scheduling|scheduling information]], BFG can produce code capable of calculating the source or destination of a field for each timestep at run-time.  An example is given in Figure 2 (below) using M1, M2 and M3; it is assumed that the arg1 field is defined in the definition data as an "OUT" argument for M1, an "INOUT" argument for M2, and an "IN" argument for M3:
+BFG is able to work out whether arg1 is input or output from each model by analysing the definition data for that model.  Coupled with the [[GENIE_BFG#Scheduling|scheduling information]], BFG can produce code capable of calculating the source or destination of a field for each timestep at run-time.  An example is given in Figure 2 (below) using M1, M2 and M3; it is assumed that the arg1 field is defined in the definition data as an "OUT" argument for M1, an "INOUT" argument for M2, and an "IN" argument for M3:
 [[Image:Introduction_to_BFG_Figure_2.png|center]]
@@ Line 122: / Line 122: @@
 </center>
-In Figure 2, M3 is not guaranteed to run sequentially after ''both'' M1 and M2 have completed and therefore the source of arg1 must be computed by ''get()'' at run-time.  The source put for the M3 get() is determined according to whether the current timestep is even: if the timestep is even, the source (or "target") of the M3 get() is the M1 put(); otherwise the target is the M2 put(). (In the current implementation of BFG2, target computation is performed by BFG functions called ''put_last()'' and ''get_next()''.)  The M3 get() call will then block until the appropriate put() has completed.  ''The fact that M2 is called every other timestep is part of the model definition data - see the <nowiki><</nowiki>timestep<nowiki>></nowiki> element of the [[GENIE:BFG files#Example Definition file|example definition file]].''
+In Figure 2, M3 is not guaranteed to run sequentially after ''both'' M1 and M2 have completed and therefore the source of arg1 must be computed by ''get()'' at run-time.  The source put for the M3 get() is determined according to whether the current timestep is even: if the timestep is even, the source (or "target") of the M3 get() is the M1 put(); otherwise the target is the M2 put(). (In the current implementation of BFG2, target computation is performed by BFG functions called ''put_last()'' and ''get_next()''.)  The M3 get() call will then block until the appropriate put() has completed.  ''The fact that M2 is called every other timestep is part of the model definition data - see the <nowiki><</nowiki>timestep<nowiki>></nowiki> element of the [[GENIE_BFG_Files#Example Definition file|example definition file]].''
 Note that it is only necessary to calculate the target of arg1 in a concurrent deployment of the model framework - M3 has been deployed in a separate executable from M1 and M2.  Where all three models share the same executable and thread, BFG does not need to insert put/get message passing and put/get target computation because the models are guaranteed to run sequentially (see the right-hand column of Table 1 for an example of sequential argpass I/O).  It would also be unnecessary to calculate the target for the M3 get() if M2 used the arg1 field solely as an "IN" argument rather than as an "INOUT" argument - in that instance, the ''only'' possible source target for arg1 would be the M1 put().
@@ Line 138: / Line 138: @@
 |-
 | [[Image:Introduction_to_BFG_Table_2_LHS.png|center]]<br>''A and O are separate executables for Atmosphere and Ocean models running concurrently. Prism_put() and prism_get() are called with timestamp data that specifies a time frame within which the data is valid.''
-| [[Image:Introduction_to_BFG_Table_2_RHS.png|center]]<br>''A and O are Atmosphere and Ocean models running sequentially.  A and O may or may not be separate executables depending on the [[GENIE:BFG#Domain decomposition|domain decomposition]] specified in the BFG deployment data. The models may be using either "inplace" or "argpass" I/O.''
+| [[Image:Introduction_to_BFG_Table_2_RHS.png|center]]<br>''A and O are Atmosphere and Ocean models running sequentially.  A and O may or may not be separate executables depending on the [[GENIE_BFG#Domain decomposition|domain decomposition]] specified in the BFG deployment data. The models may be using either "inplace" or "argpass" I/O.''
 |-
 |}
@@ Line 146: / Line 146: @@
 ===Deployment===
-'''''[[GENIE:BFG files#Example Deployment file|Example Deployment file]]'''''
+'''''[[GENIE_BFG_Files#Example Deployment file|Example Deployment file]]'''''
 BFG deployment data specifies how a model framework will be run - how many executables and MPI processes will be used, what form of I/O will be used for communication between models (e.g. MPI, sequential, OASIS...), and in what sequence model entry point functions will be called.  BFG deployment data does ''not'' specify where the model framework will be deployed - on what platform or machine it will compile or run.  Deployment data determines whether the framework (or parts of it) will run sequentially or concurrently.
@@ Line 230: / Line 230: @@
 ==See also==
-* [[GENIE:BFG files|Example BFG files]]
+* [[GENIE_BFG_Files|Example BFG files]]
-* [[GENIE:Coupling|GENIE-PRISM coupling project]]
+* [[GENIE_Coupling|GENIE-PRISM coupling project]]
 * [[GENIE_Gridspec|Draft gridspec for GENIE]]
 * [[GENIE:Internal|GENIE wiki internal pages]]

@@ Line 232: / Line 232: @@
 * [[GENIE:BFG files|Example BFG files]]
 * [[GENIE:Coupling|GENIE-PRISM coupling project]]
 * [[GENIE:Internal|GENIE wiki internal pages]]

@@ Line 222: / Line 222: @@
 ====GENIE framework generation====
-The BFG developers are currently working on an implementation of the GENIE framework that does not exchange geographical (gridded) data between models, and therefore doesn<nowiki>'</nowiki>t need OASIS or SCRIP for spatial transformations.  The GENIE framework with non-gridded coupling is a step towards generating an instance of the GENIE framework that does require gridded coupling, and carries out that coupling using OASIS.  BFG will require additional model definition data to do this - a gridspec that describes a model's grid, and can be used to generate appropriate PSMILe grid initialisation code for coupling with OASIS.  The temporal and unit transformations that are carried out in the non-gridded BFG-GENIE framework are currently being included as models in the own right.  The BFG-generated GENIE framework therefore consists of two types of model: "scientific" models, and "transform" models.  This approach may or may not be used in future - another approach would be to include transforms in the BFG metadata.
+The BFG developers are currently working on an implementation of the GENIE framework that does not exchange geographical (gridded) data between models, and therefore doesn<nowiki>'</nowiki>t need OASIS or SCRIP for spatial transformations.  The GENIE framework with non-gridded coupling is a step towards generating an instance of the GENIE framework that does require gridded coupling, and carries out that coupling using OASIS.  BFG will require additional model definition data to do this - a [[GENIE_Gridspec|gridspec]] that describes a model's grid, and can be used to generate appropriate PSMILe grid initialisation code for coupling with OASIS.  The temporal and unit transformations that are carried out in the non-gridded BFG-GENIE framework are currently being included as models in the own right.  The BFG-generated GENIE framework therefore consists of two types of model: "scientific" models, and "transform" models.  This approach may or may not be used in future - another approach would be to include transforms in the BFG metadata.
 ==BFG and FLUME==

@@ Line 72: / Line 72: @@
 ===Coupling with PRISM===
-Another development in BFG2 is the use of the PRISM coupler, OASIS (version 4).  BFG2 will effectively wrap the OASIS functionality - BFG ''put'' and ''get'' will wrap ''prism_put()'' and ''prism_get()'', and BFG will generate initialisation subroutines for each coupled model containing appropriate PRISM initialisation code that defines coupling fields ("transients" in PRISM terminology) and the grids over which those fields are exchanged by the OASIS coupler - ''prism_def_var()'', ''prism_def_grid()'', etc..  (To do this, appropriate metadata descriptions of model grids will be required - a "gridspec".)  Note that BFG2 is designed to be coupler-independent - it will be possible to create frameworks that use different coupling methods in future just by specifying appropriate metadata.
+Another development in BFG2 is the use of the PRISM coupler, OASIS (version 4).  BFG2 will effectively wrap the OASIS functionality - BFG ''put'' and ''get'' will wrap ''prism_put()'' and ''prism_get()'', and BFG will generate initialisation subroutines for each coupled model containing appropriate PRISM initialisation code that defines coupling fields ("transients" in PRISM terminology) and the grids over which those fields are exchanged by the OASIS coupler - ''prism_def_var()'', ''prism_def_grid()'', etc..  (To do this, appropriate metadata descriptions of model grids will be required - a "[[GENIE_Gridspec|gridspec]]".)  Note that BFG2 is designed to be coupler-independent - it will be possible to create frameworks that use different coupling methods in future just by specifying appropriate metadata.
 ==BFG methodology==

@@ Line 240: / Line 240: @@
 *[http://www.genie.ac.uk/ GENIE]
 *[http://www.metoffice.com/research/interproj/flume/ FLUME]
 *[http://www.earthsystemcurator.org/index.php?option=com_content&task=view&id=38&Itemid=74 Balaji's Gridspec]
-*[http://climate.lanl.gov/Software/SCRIP/ SCRIP]
+*[http://www.met.reading.ac.uk/~ian/gridspec/ My gridspec homepage]

← Older revision	Revision as of 16:59, 26 February 2007
(No difference)