Development of the simulator source code

Table of Contents

• General information about simulators architecture
  • Simulator methods sequence and framework interactions
  • OpenFLUID data types
• Handling the spatial domain
  • Parsing the spatial graph
    • Sequential parsing
    • Parallel processing using multithreading
  • Querying the spatial graph
  • Modifying the spatial graph
    • Creating and deleting spatial units
    • Adding and removing spatial connections
    • Generating spatial domain graphs automatically
• Informations about simulation time
• Simulator parameters
• Spatial attributes
• Simulation variables
• Events
• Internal state data
• Runtime environment
• Informations, warnings and errors
  • Informations and warnings from simulators
  • Errors from simulators
• Debugging
• Fortran 77/90 source code integration
• Miscellaneous helpers

General information about simulators architecture

Simulator methods sequence and framework interactions

As mentioned in the previous section, a simulator is a C++ class which defines mandatory methods (see Mandatory methods to be defined). These methods are called by the OpenFLUID framework at the right time during the simulation, following the interactions sequence in the figure below.

Among these methods, the initializeRun() and runStep() methods have a special behaviour: these two methods must return the simulation time when the simulator will be called again.
This simulation time can be

• Duration() to be called in a number of seconds given as parameter
• DefaultDeltaT() to be called in a number of seconds given as default DeltaT in the input dataset
• MultipliedDefaultDeltaT() to be called in a number of seconds given as default DeltaT in the input dataset, multiplied by a the value given as parameter
• AtTheEnd() to be called only once at the end of simulation duration
• Never() to never be called again

Example for a fixed time step simulator, with a time step equal to the default DeltaT value given in the input dataset:

openfluid::base::SchedulingRequest initializeRun()
{
  // do something here
  
  return DefaultDeltaT();
}

openfluid::base::SchedulingRequest runStep()
{
  // do something here
  
  return DefaultDeltaT();
}

Example for a variable time step simulator, based on the internal computation of the simulator:

openfluid::base::SchedulingRequest initializeRun()
{
  // do something here
  
  return DefaultDeltaT();
}

openfluid::base::SchedulingRequest runStep()
{
  double TmpValue = 0.0;

  // do something here with TmpValue

  if (TmpValue < 1.0)
    return DefaultDeltaT();
  else
    return Duration(10);
}

For fully synchronized coupled simulators, all simulators must return the same duration for the next calling, usually DefaultDeltaT() .

OpenFLUID data types

Simulation data exchanged through the OpenFLUID framework should be typed with an OpenFLUID defined type.
The available simple types are:

• openfluid::core::BooleanValue for storing boolean values
• openfluid::core::IntegerValue for storing long integer values
• openfluid::core::DoubleValue for storing double precision values
• openfluid::core::StringValue for storing string values

The available compound types are:

• openfluid::core::VectorValue for storing vector data
• openfluid::core::MatrixValue for storing matrix data
• openfluid::core::MapValue for storing associative key-value data
• openfluid::core::TreeValue for storing hierarchical key-value data

A specific type is available for storing non-existing values:

• openfluid::core::NullValue

Simulation data are stored using these types :

• Simulation variables : stored as their native type
• Spatial attributes : stored as their native type
• Simulator parameters : stored as openfluid::core::StringValue, and can be converted to any other type
• Informations associated to events : stored as openfluid::core::StringValue, and can be converted to any other type

Each data type can be converted to and from openfluid::core::StringValue (as far as the string format is correct). String representations of values are (see String representation of values)

Simulation variables can be typed or untyped. This is set at the declaration of these variables (see Simulation variables).
In case of typed variables, each value of the variable must be of the type of the variable. In case of untyped variables, values for the variable can be of any type.

Handling the spatial domain

Parsing the spatial graph

The spatial graph represents the spatial domain where coupled simulators will operate. Parsing this graph in different ways is a common task in simulators. This graph can be browsed using predefined macros.

Sequential parsing

Spatial units can be parsed following the process order by using the following OpenFLUID macros:

• OPENFLUID_UNITS_ORDERED_LOOP for parsing spatial units of a given units class
• OPENFLUID_ALLUNITS_ORDERED_LOOP for parsing of all units in the spatial domain

To parse a specific list of of spatial units, you can use the macro:

• OPENFLUID_UNITSLIST_LOOP

The source code below shows spatial graph parsing examples. The first part of the source code shows how to browse all units of the SU units class, and how to browse the "From" units for each SU unit. The second part of the source code shows how to browse all units of the spatial domain.

openfluid::base::SchedulingRequest runStep()
{
  openfluid::core::SpatialUnit* SU;
  openfluid::core::SpatialUnit* UU;
  openfluid::core::SpatialUnit* UpSU;
  openfluid::core::UnitsPtrList_t* UpSUsList;
  openfluid::core::DoubleValue TmpValue;

  OPENFLUID_UNITS_ORDERED_LOOP("SU",SU)
  {
    UpSUsList = SU->fromSpatialUnits("SU");

    OPENFLUID_UNITSLIST_LOOP(UpSUsList,UpSU)
    {
      // do something here
    }    
  }  
  
  OPENFLUID_ALLUNITS_ORDERED_LOOP(UU)
  {  
    // do something here
  }
  
  return DefaultDeltaT();
}

Parallel processing using multithreading

A process defined as a method of a simulator class can be applied in parallel to the spatial graph, following the process order, using the following methods:

• APPLY_UNITS_ORDERED_LOOP_THREADED for applying a process to a given units class. Extra arguments can be passed (see example below).
• APPLY_ALLUNITS_ORDERED_LOOP_THREADED for applying a process to a all units of the spatial domain. Extra arguments can also be passed (see example below).
  

The first argument of the method passed to the macro must be a pointer to an as it represents the currently processed spatial unit.

The code below shows how to apply a method in parallel over the spatial graph:

void computeA(openfluid::core::SpatialUnit* U)
{
 // compute something
 // can use/produce variables
}


void computeB(openfluid::core::SpatialUnit* U, 
              const double Coeff)
{
 // compute something else, with extra args
 // can use/produce variables
}


openfluid::base::SchedulingRequest runStep()
{

  APPLY_UNITS_ORDERED_LOOP_THREADED("SU",MySimulator::computeA);
  APPLY_UNITS_ORDERED_LOOP_THREADED("TU",MySimulator::computeB,2.5);
  
  APPLY_ALLUNITS_ORDERED_LOOP_THREADED(MySimulator::computeA);

  return DefaultDeltaT();
}

Please note:

• If a spatial loop is used inside other spatial loop, it is recommended to use multithreading in only one loop.
• In case of concurrent data access, it is strongly recommended to use mutex locks for thread safe data handling.

• Concurrent parsing using multithreading should improve computing performance, reducing simulations durations. But in case of very short computing durations, the cost of multithreading management may counterbalance the speed improvements of concurrent computing.

Querying the spatial graph

The spatial domain graph can be queried during simulations, in order to get informations about spatial units and connections.

The following methods are available:

• OPENFLUID_IsUnitExist
• OPENFLUID_IsUnitsClassExist
• OPENFLUID_GetUnit
• OPENFLUID_GetUnits
• OPENFLUID_GetUnitsCount
• OPENFLUID_IsUnitConnectedTo
• OPENFLUID_IsUnitConnectedFrom
• OPENFLUID_IsUnitChildOf
• OPENFLUID_IsUnitParentOf

Modifying the spatial graph

The spatial graph can be statically defined through the input dataset. It can also be defined and modified dynamically during simulations, using primitives to create and delete spatial units, and also to add and remove connections between these spatial units.
Although the creation, deletion and modification of connections are allowed at any stage of the simulation, the creation, deletion and modification of spatial units are currently allowed only during the data preparation stage (i.e. in the prepareData() method of the simulator).
For consistent use of simulators which modify the spatial domain graph, please fill the signature with the correct directives. See Spatial units graph.

Creating and deleting spatial units

In order to create and delete units, you can use the following methods:

• OPENFLUID_AddUnit
• OPENFLUID_DeleteUnit

Adding and removing spatial connections

Connections between spatial units can be of two types:

• "From-To" connections, linking spatial units topologically. These connections are usually used in "fluxes-like" processes.
• "Parent-Child" connections, linking units hierarchically.

In order to add and remove connections, you can use the following methods, whenever during simulations:

• OPENFLUID_AddFromToConnection
• OPENFLUID_AddChildParentConnection
• OPENFLUID_RemoveFromToConnection
• OPENFLUID_RemoveChildParentConnection

Example:

void prepareData()
{

 /*
      TU.1         TU.2
        |            |
        -->  TU.22 <--
               |
               --> TU.18
                     |
          TU.52 --> OU.5 <-- OU.13
                     |
                     --> OU.25

       VU1 <-> VU2

   with:
   TU1, TU2, TU22, TU18 are children of VU1
   TU52, OU5, OU13, OU25 are children of VU2
*/

  OPENFLUID_AddUnit("VU",1,1);
  OPENFLUID_AddUnit("VU",2,2);
  OPENFLUID_AddUnit("TU",1,1);
  OPENFLUID_AddUnit("TU",2,1);
  OPENFLUID_AddUnit("TU",22,2);
  OPENFLUID_AddUnit("TU",18,3);
  OPENFLUID_AddUnit("TU",52,1);
  OPENFLUID_AddUnit("OU",5,4);
  OPENFLUID_AddUnit("OU",13,1);
  OPENFLUID_AddUnit("OU",25,5);

  OPENFLUID_AddFromToConnection("VU",1,"VU",2);
  OPENFLUID_AddFromToConnection("VU",2,"VU",1);
  OPENFLUID_AddFromToConnection("TU",1,"TU",22);
  OPENFLUID_AddFromToConnection("TU",2,"TU",22);
  OPENFLUID_AddFromToConnection("TU",22,"TU",18);
  OPENFLUID_AddFromToConnection("TU",18,"OU",5);
  OPENFLUID_AddFromToConnection("TU",52,"OU",5);
  OPENFLUID_AddFromToConnection("OU",13,"OU",5);
  OPENFLUID_AddFromToConnection("OU",5,"OU",25);

  OPENFLUID_AddChildParentConnection("TU",1,"VU",1);
  OPENFLUID_AddChildParentConnection("TU",2,"VU",1);
  OPENFLUID_AddChildParentConnection("TU",22,"VU",1);
  OPENFLUID_AddChildParentConnection("TU",18,"VU",1);
  OPENFLUID_AddChildParentConnection("TU",52,"VU",2);
  OPENFLUID_AddChildParentConnection("OU",5,"VU",2);
  OPENFLUID_AddChildParentConnection("OU",13,"VU",2);
  OPENFLUID_AddChildParentConnection("OU",25,"VU",2);
}

Generating spatial domain graphs automatically

A spatial domain graph can be automatically built or extended using a provided method to create a matrix-like graph:

• OPENFLUID_BuildUnitsMatrix

Informations about simulation time

Simulators can access to informations about simulation time. There are constant time informations, such as simulation duration or begin and end date, and evolutive informations such as current time index.

Constant time informations can be accessed from any part of the simulator (except from the constructor), using the following methods:

• OPENFLUID_GetBeginDate returns the beginning date of the simulation
• OPENFLUID_GetEndDate returns the end date of the simulation
• OPENFLUID_GetSimulationDuration returns the duration of the simulation (in seconds)
• OPENFLUID_GetDefaultDeltaT returns the default time step of the simulation (in seconds), given in the input dataset

Evolutive time informations can be accessed only from specific parts of the simulator, using the following methods:

• OPENFLUID_GetCurrentTimeIndex returns the current time index (in seconds) of the simulation, and is available from the initializeRun(), runStep() and finalizeRun() methods of the simulator
• OPENFLUID_GetCurrentDate returns the current date of the simulation, and is available from the initializeRun(), runStep() and finalizeRun() methods of the simulator
• OPENFLUID_GetPreviousRunTimeIndex returns the time index corresponding to the previous execution of the simulator, and is available from the runStep() and finalizeRun() methods of the simulator

Example of code:

openfluid::base::SchedulingRequest runStep()
{
  long int Duration = OPENFLUID_GetSimulationDuration();

  long int CurrentIndex = OPENFLUID_GetCurrentTimeIndex();
  openfluid::core::DateTime CurrentDT = OPENFLUID_GetCurrentDate();  
  
  return DefaultDeltaT();      
}

Simulator parameters

Simulators parameters can be accessed in the source code from the initParams method of the simulator. Values of simulators parameters can be retreived using:

• OPENFLUID_GetSimulatorParameter.

The requested parameter name must be the same as the one used in the model.fluidx file (see Model section), or be filled from the OpenFLUID-Builder graphical interface.

Example of initParams method:

void initParams(const openfluid::ware::WareParams_t& Params)
{
  m_MyParam = 0; //default value
  OPENFLUID_GetSimulatorParameter(Params,"myparam",m_MyParam);
}

To be reused in other part of the simulator, the variable storing a simulator parameter should be declared as class member. The types of parameters can be string, double, integer, boolean, vector of string, vector of double (see API documentation of OPENFLUID_GetSimulatorParameter method to get more informations about other available types, available on OpenFLUID web site).

Spatial attributes

In order to access or update values of spatial attributes, or to test if a spatial attribute is present, you can use the following methods:

• OPENFLUID_GetAttribute to get the value of an attribute
• OPENFLUID_SetAttribute to set the value of an attribute
• OPENFLUID_IsAttributeExist to to test if an attribute exists

The methods to test if an attribute exists or to access to an attribute value are usable from any simulators part except from the initParams() part. The methods to update an attribute value are only usable from the prepareData() and checkConsistency() parts of the simulator.
The names of the attributes must match the names in the input dataset (see Spatial domain section), or the name of an attribute created by a simulator.

Example of use:

openfluid::base::SchedulingRequest runStep()
{
  openfluid::core::SpatialUnit* SU;
  openfluid::core::DoubleValue AreaValue;

  OPENFLUID_UNITS_ORDERED_LOOP("SU",SU)
  {
    OPENFLUID_GetAttribute(SU,"area",AreaValue);
    
    // continue with source code using the value of the area attribute
  }
}

Simulation variables

The values for the simulation variables are attached to the spatial units.

The available methods to access to simulation variables are:

• OPENFLUID_GetVariable to get the value of a variable at the current time index or at a given time index
• OPENFLUID_GetVariables to get values of a variable between two times indexes
• OPENFLUID_GetLatestVariable to get the latest available value for the variable
• OPENFLUID_GetLatestVariables to get the latest values of a variable since a given time index

The available methods to add or update a value of a simulation variable are:

• OPENFLUID_AppendVariable to add a value to a variable for the current time index
• OPENFLUID_SetVariable to update the value of a variable for the current time index

The available methods to test if a simulation variable exists are:

• OPENFLUID_IsVariableExist to test if a variable exists or if a value for this variable exists at the given time index
• OPENFLUID_IsTypedVariableExist to test if a variable exists or if a value for this variable exists at the given time index, and its type matches the given type

These methods can be accessed only from the initializeRun(), runStep() and finalizeRun() parts of the simulator.

Example:

openfluid::base::SchedulingRequest runStep()
{
  openfluid::core::DoubleValue TmpValue;
  openfluid::core::SpatialUnit* SU;

  OPENFLUID_UNITS_ORDERED_LOOP("SU",SU)
  {
    OPENFLUID_GetVariable(SU,"MyVar",TmpValue);
    TmpValue = TmpValue * 2;
    OPENFLUID_AppendVariable(SU,"MyVarX2",TmpValue);
  }
  
  return DefaultDeltaT();
}

Events

A discrete event is defined by the class. It is made of a date and a set of key-value informations that can be accessed by methods proposed by the openfluid::core::Event class.
A collection of discrete events can be contained in an openfluid::core::EventsCollection class.

A collection of events occuring during a period on a given spatial unit can be acessed using

• OPENFLUID_GetEvents

This method returns an that can be processed.
The returned event collection can be parsed using the specific loop macro:

• OPENFLUID_EVENT_COLLECTION_LOOP

At each loop iteration, the next event can be processed.

An event can be added on a specific spatial unit at a given date using:

• OPENFLUID_AppendEvent

Example of process of events occurring on the current time step:

openfluid::base::SchedulingRequest runStep()
{
  openfluid::core::SpatialUnit* TU;
  openfluid::core::EventCollection EvColl;
  openfluid::core::Event* Ev;
  std::list<openfluid::core::Event* > *EvList;
  openfluid::core::DateTime BTime, ETime;

  BTime = OPENFLUID_GetCurrentDate();
  ETime = OPENFLUID_GetCurrentDate() - 86400;

  OPENFLUID_UNITS_ORDERED_LOOP("TU",TU)
  {
    OPENFLUID_GetEvents(TU,BTime,ETime,EvColl);
    EvList = EvColl.getEventsList();

    OPENFLUID_EVENT_COLLECTION_LOOP(EvColl.getEventsList(),Ev)
    {
      if (Ev->isInfoEquals("molecule","glyphosate"))
      {
        // process the event
      }
    }

  }

  return DefaultDeltaT();
}

Internal state data

In order to keep the status of the simulation function between calls (from the run step to the next one for example), internal variables can be stored as class members. The class members are persistant during the whole life of the simulator.
To store distributed values, data structures are available to associate a spatial unit ID to a storedvalue. These data structures exist for different types of data:

• openfluid::core::IDFloatMap
• openfluid::core::IDDoubleMap
• openfluid::core::IDIntMap
• openfluid::core::IDBoolMap
• openfluid::core::IDDoubleValueMap
• openfluid::core::IDVectorValueMap
• openfluid::core::IDVectorValuePtrMap
• openfluid::core::IDSerieOfDoubleValueMap
• openfluid::core::IDSerieOfDoubleValuePtrMap

Example of declaration of ID-map structures in private members of the simulator class:

class MySimulator : public openfluid::ware::PluggableSimulator
{
  private:

    openfluid::core::IDDoubleMap m_LastValue;

  public:
  
    // rest of the simulator class

}

Example of usage of the ID-map structures:

openfluid::base::SchedulingRequest runStep()@tableofcontents
{
  int ID;
  double TmpValue;
  openfluid::core::SpatialUnit* SU;

  OPENFLUID_UNITS_ORDERED_LOOP("SU",SU)
  {
    ID = SU->getID();

    TmpValue = TmpValue + m_LastValue[ID]
    OPENFLUID_AppendVariable(SU,"MyVarPlus",TmpValue);

    m_LastValue[ID] = TmpValue;
  }

  return DefaultDeltaT();
}

Runtime environment

The runtime environment of the simulator are informations about the context during execution of the simulation: input and output directories, temporary directory,...
They are accessible from simulators using:

• OPENFLUID_GetRunEnvironment method.

Example:

openfluid::base::SchedulingRequest initializeRun()
{
  std::string InputDir;

  OPENFLUID_GetRunEnvironment("dir.input",InputDir);

  // the current input directory is now available through the InputDir local variable 

  return DefaultDeltaT();
}

The keys for requesting runtime environment information are:

• dir.input [string] : the current input directory
• dir.output [string] : the current output directory
• dir.temp [string] : the directory for temporary files
• mode.cleanoutput [boolean] : cleaning output dir before data saving is enabled/disabled
• mode.saveresults [boolean] : result saving in output directory is enabled/disabled
• mode.writereport [boolean] : simulation report saving is enabled/disabled

Informations, warnings and errors

Informations and warnings from simulators

Simulators can emit informations and warnings to both console and files using various methods

• OPENFLUID_DisplayInfo to display informative messages to console only
• OPENFLUID_LogInfo to log informative messages to file only
• OPENFLUID_LogAndDisplayInfo to log and display informative messages simultaneously
• OPENFLUID_DisplayWarning to display warning messages to console only
• OPENFLUID_LogWarning to log warning messages to file only
• OPENFLUID_LogAndDisplayWarning to log and display warning messages simultaneously

Using these methods is the recommended way to log and display messages. Please avoid using std::cout or similar C++ facilities in production or released simulators.

Example:

openfluid::base::SchedulingRequest runStep()
{
  openfluid::core::SpatialUnit* TU;

  OPENFLUID_UNITS_ORDERED_LOOP("TestUnits",TU)
  {
    OPENFLUID_LogInfo("TestUnits #" << TU->getID());
    OPENFLUID_DisplayInfo("TestUnits #" << TU->getID());

    OPENFLUID_LogWarning("This is a warning message for " << "TestUnits #" << TU->getID());
  }

  return DefaultDeltaT;
}

The messages logged to file are put in the openfluid-messages.log file placed in the simulation output directory. This file can be browsed using the openfluid-logexplorer program or using the OpenFLUID-Builder application.

Errors from simulators

Simulators can raise errors to notify the OpenFLUID framework that something wrong or critical had happened. An error stops the simulation the next time the OpenFLUID framework has the control.

Errors can be raised using OPENFLUID_RaiseError

Example:

void checkConsistency()
{
  double TmpValue;
  openfluid::core::SpatialUnit* SU;
    
  OPENFLUID_UNITS_ORDERED_LOOP("SU",SU)
  {
    OPENFLUID_GetAttribute(SU,"MyAttr",TmpValue);
    
    if (TmpValue <= 0)
    {
      OPENFLUID_RaiseError("Wrong value for the MyProp distributed property on SU");
      return false;
    }    
  }
}

Debugging

Debugging macros allow developpers to trace various information during simulations.
They are enabled only when debug is enabled at simulators builds. They are ignored for other build types.

In order to enable debug build mode, the option -DCMAKE_BUILD_TYPE=Debug must be added to the cmake command (e.g. cmake <srcpath> -DCMAKE_BUILD_TYPE=Debug).

Example of build configuration:

cmake .. -DCMAKE_BUILD_TYPE=Debug

This debug build mode is disabled using the release build mode, with the option -DCMAKE_BUILD_TYPE=Release.

Simulators can emit debug information to both console and files using various methods

• OPENFLUID_DisplayDebug to display debug messages to console only
• OPENFLUID_LogDebug to log debug messages to file only
• OPENFLUID_LogAndDisplayDebug to log and display debug messages simultaneously

Example:

openfluid::base::SchedulingRequest runStep()
{
  OPENFLUID_LogDebug("Entering runStep at time index " << OPENFLUID_GetCurrentTimeIndex());

  return DefaultDeltaT;
}

Additional macros are available for debugging:

• OFDBG_LOCATE for file/line location where the macro is called
• OFDBG_MESSAGE adding the message given as an argument
• OFDBG_UNIT for information about the unit given as an argument
• OFDBG_UNIT_EXTENDED for extended information about the unit given as an argument
• OFDBG_EVENT for information about the event given as an argument
• OFDBG_EVENTCOLLECTION for information about the event collection given as an argument

Example:

openfluid::base::SchedulingRequest runStep()
{
  openfluid::core::SpatialUnit* TU;
  openfluid::core::DateTime BeginDate,EndDate;
  openfluid::core::EventsCollection EvColl;

  OFDBG_LOCATE;

  BeginDate = OPENFLUID_GetCurrentDate();
  EndDate = OPENFLUID_GetCurrentDate() + OPENFLUID_GetDefaultDeltaT() - 1;


  OPENFLUID_UNITS_ORDERED_LOOP("TU",TU)
  {
     OFDBG_UNIT_EXTENDED(TU);

     EvColl.clear();
     OPENFLUID_GetEvents(TU,BeginDate,EndDate,EvColl);
     OFDBG_EVENTCOLLECTION(EvColl);
  }

  return DefaultDeltaT();
}

Fortran 77/90 source code integration

The C++ - Fortran interface is defined in the openfluid/tools/FortranCPP.hpp file. In order to execute Fortran code from a simulator, this Fortran source code have to be wrapped into subroutines that will be called from the C++ code of the simulation function.
To help developers of simulators to achieve this wrapping operation, the FortranCPP.hpp file defines macros. These macros allows calls of Fortran77 and Fortran90 source code. You are invited to read the FortranCPP.hpp file to get more information about these macros.

Example of Fortran source code (FSubr.f90):

subroutine displayvector(Fsize,vect)

implicit none

integer Fsize,ifrom
real*8 vect(Fsize)

write(*,*) 'size',Fsize
write(*,*) (vect(i),i=1,Fsize)

return
end

Example of declaration block int the .cpp file (MySim.cpp):

BEGIN_EXTERN_FORTRAN
  EXTERN_FSUBROUTINE(displayvector)(FINT *Size, FREAL8 *Vect);
END_EXTERN_FORTRAN

Example of call of the fortran subroutine from the initializeRun method (MySim.cpp):

#include <openfluid/tools/FortranCPP.hpp>

openfluid::base::SchedulingRequest initializeRun()
{
  openfluid::core::VectorValue MyVect;
  
  MyVect = openfluid::core::VectorValue(15,9);
  int Size = MyVect.getSize();

  CALL_FSUBROUTINE(displayvector)(&Size,(MyVect.getData()));

  return DefaultDeltaT();
}

The compilation and linking of Fortran source code is automatically done when adding fortran source files to the SIM_FORTRAN variable in the CMake.in.config file (See File CMake.in.config containing the build configuration).

Miscellaneous helpers

The OpenFLUID API provides miscellaneous functions and classes to help simulators developpers in their setup of data processing or numerical computation. They are available in various namespaces:

• openfluid::tools
• openfluid::scientific
• openfluid::utils

In order to use these helpers, the corresponding headers files must be included in the simulator source code.

As they are not detailed here in this manual, more informations about these helpers are available in the provided header files (.hpp), located in the corresponding include directories.