In Octopus there is the possibility to group several systems into containers, which are implemented in the multisystem_basic_t class.
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
Implementation
Most of the functionality is implemented at the level of the abstract class multisystem_t:
Definition of multisystem_t
type,extends(system_t),abstract::multisystem_ttype(system_list_t)::listcontains
procedure::execute_algorithm=>multisystem_execute_algorithmprocedure::init_parallelization=>multisystem_init_parallelizationprocedure::next_time_on_largest_dt=>multisystem_next_time_on_largest_dtprocedure::reset_iteration_counters=>multisystem_reset_iteration_countersprocedure::init_algorithm=>multisystem_init_algorithmprocedure::algorithm_finished=>multisystem_algorithm_finishedprocedure::init_iteration_counters=>multisystem_init_iteration_countersprocedure::propagation_start=>multisystem_propagation_startprocedure::propagation_finish=>multisystem_propagation_finishprocedure::init_all_interactions=>multisystem_init_all_interactionsprocedure::init_interaction=>multisystem_init_interactionprocedure::write_interaction_graph=>multisystem_write_interaction_graphprocedure::initial_conditions=>multisystem_initial_conditionsprocedure::do_algorithmic_operation=>multisystem_do_algorithmic_operationprocedure::is_tolerance_reached=>multisystem_is_tolerance_reachedprocedure::update_quantity=>multisystem_update_quantityprocedure::init_interaction_as_partner=>multisystem_init_interaction_as_partnerprocedure::copy_quantities_to_interaction=>multisystem_copy_quantities_to_interactionprocedure::process_is_slave=>multisystem_process_is_slaveprocedure::start_barrier=>multisystem_start_barrierprocedure::end_barrier=>multisystem_end_barrierprocedure::arrived_at_barrier=>multisystem_arrived_at_barrierprocedure::restart_write=>multisystem_restart_writeprocedure::restart_read=>multisystem_restart_readprocedure::restart_write_data=>multisystem_restart_write_dataprocedure::restart_read_data=>multisystem_restart_read_dataprocedure::update_kinetic_energy=>multisystem_update_kinetic_energyprocedure::update_potential_energy=>multisystem_update_potential_energyprocedure::update_internal_energy=>multisystem_update_internal_energyprocedure::get_flat_list=>multisystem_get_flat_listend type multisystem_t
The specific multisystem_basic_t class only adds the finalizer:
Definition of multisystem_basic_t
type,extends(multisystem_t)::multisystem_basic_tcontains
final::multisystem_basic_finalizerend type multisystem_basic_t