Copy fields during a Problem execution : Developing a new `Task` node.

[AntoineMazuyer]

Related to my project of coarsening / Mohammad's method.

@cssherman and I made a good progress by using the EventManager to triggers the first three Flow simulations at the fine scale using three "fake" time steps.

I am now investigating on how to save the pressure field at each time step, because I will have to have access to them to upscale the transmissibilities between the aggregates.

I was thinking of having a new node : Task, which is at the same level than Solvers. TaskBase will be an ExecutableGroup and CopyField will inherit from TaskBase. Of course, TaskBase can be derived in the future for other application cases.

TaskManager
TaskBase
  |
  |
   CopyField
  |
  |
   AnotherFutureClassForSomeApplications

In the XML file, it will lead to something like :

    <SinglePhaseFlow name="SinglePhaseFlow"
                     verboseLevel="0"
                     gravityFlag="1"
                     discretization="singlePhaseTPFA"
                     fluidName="water"
                     solidName="rock"
                     targetRegions="Region2">
      <SystemSolverParameters krylovTol="1.0e-10"
                              newtonTol="1.0e-6"
                              maxIterNewton="8"/>
    </SinglePhaseFlow>

    <Tasks>
       <CopyField name="copyPressure"
                          from="pressure"
                          to="copiedPressure" />
    </Tasks>

   <Events maxTime="10.0" verbosity="1">
     <PeriodicEvent name="event_a"
                    forceDt="1.0"
                    endTime="4"
                    target="/Solvers/SinglePhaseFlow" />
     <SoloEvent name="event_b"
               targetTime="4"
               target="/Tasks/copyPressure" />
     </Events>

Any thoughts about that or any idea about a workaround for my specific use case ?

[cssherman]

I think that this seems reasonable feature to add. In the old code, there was no uniform way we handled these sort of disparate tasks (we had everything from a physics solver handling .csv outputs to a boundary condition triggering the calculation of element centers).

@rrsettgast - any thoughts?

[rrsettgast]

Actually I think we can take it further. So correct me if I misunderstand but I think of this as using the event manager as a means to couple events (solver and task) at runtime instead of in a dedicated solver. I will always lean towards the dedicated coupled solver approach but that doesn’t mean that we can’t have a flexible task scheduler as a research tool. So instead of a single task that is interleaved in the event manager how about the ability to encapsulate multiple processes in a periodic event? That way you could arrange single execution events in a periodic fashion. As I am typing this I am thinking we already can do this?

Anyways maybe don’t have a separate Task block but instead generalize the solver block to be a task block. Thoughts?

[cssherman]

I definitely agree with your thoughts on coupled solvers, and the use for this as a research tool. I'm OK with specifying these in a unified task block, as long as it doesn't end up being too cluttered. And yes - the task manager is built to handle arbitrary nested events (it isn't being leveraged in any of the examples in the repo yet though). For instance:

<Events maxTime="1.0">
    <PeriodicEvent name="eventGroup"
                   forceDt="1.0" >
        <PeriodicEvent name="solverApplications"
                       target="/Solvers/laplace" >
        <PeriodicEvent name="somethingElse"
                       target="/Solvers/otherTask" >
    </PeriodicEvent>

    <PeriodicEvent name="outputs"
                   timeFrequency="1.0"
                   targetExactTimestep="1"
                   target="/Outputs/siloOutput" />
  </Events>

[AntoineMazuyer]

@rrsettgast So :

So correct me if I misunderstand but I think of this as using the event manager as a means to couple events (solver and task) at runtime instead of in a dedicated solver.

The goal is to use the EventManager to insert some steps (which are not solvers) between solvers to use GEOSX as an integrated tools to solve "complex problem" which require some steps, depending of the used method.

So instead of a single task that is interleaved in the event manager how about the ability to encapsulate multiple processes in a periodic event?

yes we can do that, but why not using the SoloEvent ? to my mind is more straightforward

Anyways maybe don’t have a separate Task block but instead generalize the solver block to be a task block.

This is a philosophic question. We can say that Solvers and Output are Tasks, as well as homemade task (like my CopyField). So maybe we can have a Task block with all of that in it ? Because a Task like CopyField will not be a Solver.

[corbett5]

Can this be closed?

[wrtobin]

This has been half-addressed. We have Tasks by virtue of their use/need in the time-history work, but we do not currently have a CopyField task.