Reorganize a bit the structure of the wall files

[tulioricci]

Some cosmetic changes and initial steps towards a more thorough refactor of the gas-wall structure (#930)

• some renaming regarding the wall calculations that I believe to make more sense now
• moved the classes that are used for heat conduction only from driver to wall_model
• moved the mask_from_elements to utils
• new fluid state encapsulation PorousFlowFluidState to uncouple the wall density from dv to the new wv, as well as existing wall dependent vars wdv to wv
• new GasModel-like encapsulation PorousFlowModel that considers the wall thermophysical properties.
• new transport class PorousWallTransport coupling gas and wall properties
• everything that is used exclusively by the ablation_workshop example is inside that driver. Now the material files are cleaner and more "prediction targeted"

Questions for the review @MTCam:

After quick first pass, looks good to me, just need to have a more detailed look to check the rest of the boxes.

• Is the scope and purpose of the PR clear?
  • The PR should have a description.
  • The PR should have a guide if needed (e.g., an ordering).
• Is every top-level method and class documented? Are things that should be documented actually so?
• Is the interface understandable? (I.e. can someone figure out what stuff does?) Is it well-defined?
• Does the implementation do what the docstring claims?
• Is everything that is implemented covered by tests?
• Do you see any immediate risks or performance disadvantages with the design? Example: what do interface normals attach to?

[majosm]

I forgot to mention: I have an idea to simplify make_fluid_state a little. I'll give it a shot, and if it pans out I'll make a PR (I won't let that hold up this PR though).

[tulioricci]

Hi @majosm, I think I covered all the points you raised. I couldn't reply directly wrt the eos and wall_eos in the transport variables, but with the latest changes, now it has the same structure of pure gas. I don't know if it is worth to remove one argument but add the classes in the init, as you suggested. It doesn't look like a significant improvement.

Also, note that I renamed wall_model in PorousFlowModel to wall_eos to keep consistency with the gas nomenclature. Hopefully this also helps makes things more clear.

[MTCam]

Suggested change

	def gas_const(self, cv: Optional[ConservedVars] = None, temperature=None):
	def gas_const(self, cv: Optional[ConservedVars] = None, temperature: Optional[DOFArray] = None):

[MTCam]

Suggested change

	def gas_const(self, cv: ConservedVars, # type: ignore[override]
	temperature=None):
	def gas_const(self, cv: ConservedVars, # type: ignore[override]
	temperature: Optional[DOFArray] = None):

[MTCam]

tbh, I do not see any real harm in internalizing some of our use-specific constructs. If it makes it easier for us (and others) to use, then we should. Is that the question, or did I miss the mark?

[tulioricci]

The original comment was here: #875 (comment)

Just keeping in the code as a reminder for the coupling PR which will effectively use the models. I suggest we postpone the discussion on this.

[MTCam]

👍 Looks like a net positive change to me. It is hard to tell what all the implications are, and the unintended effects. We'll just have to use it and find out, heh.

[majosm]

Just a few more suggestions, otherwise looks good. 👍

[majosm]

👍 Looks good on my end.