Refactoring

[AlexJamesWright]

Looking at the code now, the number of files has grown a fair bit compared to the early days---there are multiple source files with implementations save data, bounday conditions, time integrators, models etc.---and the src/ and include/ directories are beginning to become a bit of a mess. I'm going to spend a bit of time looking at refactoring the layout and organising things in a better way. Doing this is likely going to cause some problems along the way, so might be a pain.

Rough plan for layout:

METHOD/
Project/
CPU/
Include/
TimeIntegrators/
Physics/
BoundaryConditions/
....
Src/
TimeIntegrators/
Physics/
BoundaryConditions/
....
etc.

I'm probably going to hold off doing the same for the GPU for now but this will need to be done too for consistency. If anyone has any ideas/comments/thinks it's a waste of time just let me know!

[IanHawke]

I can't decide how tightly coupled some of these are going to be: for the Israel Stewart stuff that Marcus is working on (hence the toyq branch stuff) there's time derivatives that need computing for source terms, and it's unclear how that should interact with the time integrators: may need to tightly couple.

[AlexJamesWright]

Do you have a reference for me to look at? It might be simplest to store the previous variables needed for the derivative as auxiliaries and update them as needed in model->finalise thats called after every sub-step in the integration

[AlexJamesWright]

E.g. when calling

METHOD/Project/CPU/Include/timeInt.h

Line 129 in 89917b2

model->finalise(cons, prims, aux);

after each substep, doing

  var_pp = var_p
  var_p = var

[AlexJamesWright]

I have finished the refactoring for the CPU code in f795413, please let me know if you're happy with it and whether you think it can be merged (bearing in mind there might be some friction). Have you thought anymore about the coupling you mentioned? @IanHawke