In Octopus there is the possibility to group several systems into containers, which are implemented in the
Containers can have different purposes and applications. In the simplest case, containers are simply a collection of other systems, and do not have their own interactions with anything else. In this case, containers do not introduce any different physics (or approximations), but simply help in the book-keeping of the problem.
Containers do not correspond to a given region in space, but only to a selection of systems. In many cases, these systems might be confined to a certain region in space, but this is not a property of the container. In many other cases, e.g. combining matter and maxwell fields, both systems occupy the same space, or have a substantial overlap.
Another use case might be to group systems into a container, and then only interact with the whole container, instead of the individual systems. This, however, is an approximation, and furthermore (at least, at the moment) has some limitations due to the implementation.
Note, that containers themselves do not move. This has consequences to the definition of the energy contributions. In particular, a container does not have it’s own kinetic energy, and all kinetic energy contributions of the constituents are accounted for in the internal energy. For more information, see Calculating Energies
Most of the functionality is implemented at the level of the abstract class
type, extends(system_t), abstract :: multisystem_t type(system_list_t) :: list contains procedure :: execute_algorithm => multisystem_execute_algorithm procedure :: init_parallelization => multisystem_init_parallelization procedure :: next_time_on_largest_dt => multisystem_next_time_on_largest_dt procedure :: reset_clocks => multisystem_reset_clocks procedure :: init_algorithm => multisystem_init_algorithm procedure :: algorithm_finished => multisystem_algorithm_finished procedure :: init_clocks => multisystem_init_clocks procedure :: propagation_start => multisystem_propagation_start procedure :: propagation_finish => multisystem_propagation_finish procedure :: init_all_interactions => multisystem_init_all_interactions procedure :: init_interaction => multisystem_init_interaction procedure :: write_interaction_graph => multisystem_write_interaction_graph procedure :: initial_conditions => multisystem_initial_conditions procedure :: do_algorithmic_operation => multisystem_do_algorithmic_operation procedure :: is_tolerance_reached => multisystem_is_tolerance_reached procedure :: update_quantity => multisystem_update_quantity procedure :: init_interaction_as_partner => multisystem_init_interaction_as_partner procedure :: copy_quantities_to_interaction => multisystem_copy_quantities_to_interaction procedure :: process_is_slave => multisystem_process_is_slave procedure :: start_barrier => multisystem_start_barrier procedure :: end_barrier => multisystem_end_barrier procedure :: arrived_at_barrier => multisystem_arrived_at_barrier procedure :: restart_write => multisystem_restart_write procedure :: restart_read => multisystem_restart_read procedure :: restart_write_data => multisystem_restart_write_data procedure :: restart_read_data => multisystem_restart_read_data procedure :: update_kinetic_energy => multisystem_update_kinetic_energy procedure :: update_potential_energy => multisystem_update_potential_energy procedure :: update_internal_energy => multisystem_update_internal_energy procedure :: get_flat_list => multisystem_get_flat_list end type multisystem_t
multisystem_basic_t class only adds the finalizer:
type, extends(multisystem_t) :: multisystem_basic_t contains final :: multisystem_basic_finalizer end type multisystem_basic_t