3.16.3.2. Scheduling¶
Radiative transfer tasks need not be updated with the same cadence as their MHD “host” tasks. The scheduling relations are illustrated below.
Phase 1: MHD updates are done, until mhd%time >= mhd%rt_next
(=omega%time
for all omega)::
------------- BC --------------------------------------
------------- MHD1 ------------+ |
--------------RT1 ---------------+
|
------------- MHD2 -------------+ |
--------------RT2 ---------------+
Phase 2: EOS2 calculations, at time = mhd%rt_next
, setting eos_time
to this
time. Here, EOS2 has advanced, and with MHD2 time ahead, only lack of upstream
RT prevents RT2 update:
------------- BC --------------------------------------
------------- MHD1 -------------+ |
--------------RT1 ---------------+
|
------------- MHD2 ---------------|-+
--------------EOS2 ---------------+
--------------RT2 ---------------+
Phase 3: EOS1 calculations, at time = mhd%rt_next
, setting eos_time
to this
time. Here, EOS2 has advanced, and with MHD2 time ahead, only lack of upstream
RT prevents RT2 update:
------------- BC --------------------------------------
------------- MHD1 ---------------|+
--------------RT1 ---------------+
|
------------- MHD2 ---------------|-+
--------------EOS2 ---------------+
--------------RT2 ---------------+
Phase 4: RT1 is now detected as “ready”, while RT2 is waiting:
------------- BC --------------------------------------
------------- MHD1 ---------------|+
--------------RT1 ---------------|--------+
|
------------- MHD2 ---------------|-+
--------------EOS2 ---------------+
--------------RT2 ---------------|--------+
If the RT update time rt_time
is smaller than mhd%dtime
, it could happen that
the next time the MHD task is updated, it finds itself still ahead of the RT
time, and hence that MHD task (but not all of them, advances it’s RT time again).
A simple solution would be to limit the MHD update time interval to rt_time
, for
all patches that do RT. This could impact the cost a bit, but only when the
choice of RT time is made very conservative