DISPATCH
rt_mod Module Reference

Module to set up angles and bins for an RT patch with only absorption. This means that the only extra memory with time slot that is needed is one slot for the net radiation heating, Q_bin_angle. More...

Data Types

type  rt_t
 

Variables

integer, save verbose =0
 
type(rt_t), public rt
 

Detailed Description

Module to set up angles and bins for an RT patch with only absorption. This means that the only extra memory with time slot that is needed is one slot for the net radiation heating, Q_bin_angle.

The data structure consists of self, an extension of the gpatch_t data type, which also contains n_omega clones of itself, with the specific info for each ray direction. Since the data type is an extension of patch_t, we can use the standard guard zone loading procedures in download_mod or data_hub_mod to fill the RT guard zones, and since the sub-tasks and main task have the same data type, the sub-tasks can be cloned from the main task.

Since directional information becomes available at different times, the guard zone filling must take place for each angle, just before the solver is called.

The selftime, selfrt_timestep, and selfrt_next control the scheduling of the tasks. The MHD tasks require that the times of their nbors are "ahead", allowing for a grace fraction of the nbor time step. The RT sub-tasks advance their time by selfrt_timestep (effectively their selfdtime) when done, hence they must update when their MHD master task passes their own time, which conforms with standard nbor relations. To clarify, with the times

MHD time: mhdtime RT time: mhdrttime ray time: mhdrtomegatime

The RT_time is a "rabbit time", which gives the time until which the MHD task should still be happy with the RT solution. When the parent MHD task passes that time, the RT sub-tasks become out-of-date, and they perform solutions. Afterwards, they advance their "rabbit time" again, and when all of them have done so, the main RT task becomes ready to update, and when it runs it sums up the sub-task contributions, and advances its own "rabbit time", which then allows the MHD task to update. Clearly, the EOS call that gives values to the RT tasks at the new MHD time has to be made after the MHD task has passed by, but before the first sub-task executes. This could be detected either in the MHD task, or in the RT sub-tasks, where the first detection should lead to locking the EOS while executing it, followed by another test (so a double critical region type of thing).

Initially, we wish that only the RT states are ready to update, and we set things up to compute the EOS, solve the RT, sum up Q, and only then let the MHD update. This means that initially, the EOS_time should be negative, the RT times should be RT_timestep/2 negative, and the MHD_time should be zero.