Boundary and Initial conditions directory structure of Aspect

[gassmoeller]

Boundary and Initial conditions directory structure of Aspect

[bangerth]

I'm for it. As far as directory structure is concerned, this is something that has long bothered me as well. If we want to be anal, we could leave the old directories under include/aspect and have an interface.h in each that simply #includes the new one, but I think even that may not be necessary. I'd think people understand that they might need to update their plugins between ASPECT versions.

I currently have 4 big branches open. Can we make these changes once all big branches have been merged?

I don't know whether you intended to also rename the sections in the .prm files to be more consistent. That's a bigger issue because it breaks everyone's .prm files. I think this may be too much to be worth the pain.

[gassmoeller]

Yes renaming the sections in the parameter files seems to be a bit too much. However I ran into a similar inconsistency that might be worth thinking about for a moment. We map boundaries to different velocity boundary condition plugins, but assume that one plugin can describe all boundary conditions for temperature and composition. I currently need temperature boundary conditions that are different depending on the boundary indicator. I will write my own boundary temperature plugin, but what it will do is essentially using the existing initial_temperature plugin code for every boundary except from the bottom boundary, so a similar map as we use for the velocity could save me from copying that code to a new plugin.
Would this be worth considering? Unfortunately, it would mess up the input files as well.

And of course we can wait with the above mentioned renaming until no large branches are awaiting their merge to keep conflicts as small as possible.

[tjhei]

change directory structure

agreed

leave the old directories under include/aspect

I am not too thrilled about it.

break .prms

I think this is okay to do. The current naming is quite confusing. If we change the directory structure the sections and directories should match up and not be different.

We map boundaries to different velocity boundary condition plugins, but assume that one plugin can describe all boundary conditions for temperature and composition.

This is also a good idea. Things handled in a uniform way is a big plus.

[tjhei]

I vote for also redoing the parameter sections while we are at it and make it more flexible. I was thinking something like this:

subsection boundary conditions
  subsection Velocity
    set conditions = left: tangential, right: zero, top: function, bottom: SomePluginName
    subsection function
      set function = bla
    end
  end
  subsection Temperature
    set conditions = left: periodic, right: periodic, top: function, bottom: initial
end

subsection Initial conditions
  like above
end

The idea is that there is one list for the indicators and you can pick between all kind of plugins and different types of boundaries.

This has many advantages:

• it is more flexible (right now you can only pick a single model for temperature)
• easier to validate that each boundary has exactly one condition (in the code and for the user)
• it is the same for all types of boundaries

[gassmoeller]

Closed by #1449 and #1451.