System destructor requires the mesh to still be around, through the dof map

[GiudGiud]

System destructor requires the mesh to still be around, through the dof map

[roystgnr]

Neither case is ownership, just reference.

The EquationSystems owns the System, not the other way around, but the System may need to use the EquationSystems that owns it, so it keeps a reference. The EquationSystems thus needs to destroy the System before it can finish destroying itself, but because it owns the System that's not so hard.

The System doesn't own the Mesh or vice-versa, but the System needs to use the Mesh, so it keeps a reference to it. It wouldn't make any sense for the System to own the Mesh, since you can have multiple systems on a Mesh or zero systems on a Mesh, but as long as the System needs to access the Mesh (including during its own destructor) we can't let the latter be destroyed before the former, and in this case since the user code owns both the EquationSystems and the Mesh that destruction ordering is unfortunately not in the library's hands.

It'd be awesome if we could avoid the ability to create dangling references, and we could maybe do some shared_ptr/weak_ptr trickery in that vein in some cases, but even if we managed to do so in every case we can without creating leaks, I don't think it would buy us much. The bug

Mesh * m = new Mesh(comm);
EquationSystems es(*m);
delete m;

is just fancier names applied to the bug

int * i = new int(42);
int & iref(*i);
delete i;
iref = 5;

and the only fix for the latter is "don't use C++".

[GiudGiud]

maybe the DisplacedSystem should just keep a shared_ptr to the DisplacedMesh ?

[lindsayad]

• or remove shared pointer to displacedProblem from SolveObject

Yea I don't think that the SolveObject needs to be an owner of the DisplacedProblem

[GiudGiud]

I agree with that too.
Should the displacedSystem be an owner of the DisplacedMesh to naturally order the destruction?

[lindsayad]

I don't think that would be a natural ordering. I think the algebraic objects should destroy before the geometric ones

[lindsayad]

Like I believe this is the right kind of ordering in the ActionWarehouse

  /// Mesh class
  std::shared_ptr<MooseMesh> _mesh;

  /// Possible mesh for displaced problem
  std::shared_ptr<MooseMesh> _displaced_mesh;

  /// Problem class
  std::shared_ptr<FEProblemBase> _problem;

[roystgnr]

Can you use a Mesh without a System? Yes - we do all the time.

Can you use a System without a Mesh? No. In a conceptual sense, perhaps you should be able to? But for data locality reasons the System writes and reads its own data to the Mesh (putting DoF indexing on each DofObject), and that's not going to change any time soon. In an API sense, you can't construct an System without passing the EquationSystems it should reference to its destructor, you can't construct an EquationSystems without giving it a reference to the mesh to use, and "destruct things in the opposite order you construct them" is a heuristic so standard that it's literally built into the C++ language for stack objects; you're able to mix up the order when you're manually managing heap objects, but you're not actually supposed to use any of the many footguns C++ provides.

[GiudGiud]

So System should (co-)own EquationSystem which should (co-)own the Mesh?

or are you saying we should avoid shared pointers (and rely on a healthy ordering in classes) as it's shooting us in the foot here

[lindsayad]

We should destroy objects with references to the MeshBase before we destroy the MeshBase. We should probably reduce some of the shared_ptr usage in MOOSE as it does, by definition, remove some clarity of ownership

[lindsayad]

Like we should make sure this doesn't happen:

The displaced problem is destructed AFTER the displaced mesh

[lindsayad]

Closing this as it should be expected that the mesh should still be around at the time of destruction given the chain of references in construction that @roystgnr pointed out. We can of course keep discussing the topic though