code re-structuring

[ajgoza]

• better names for types and structs?
• maybe break up into several files based on the category of each type (so maybe grid types and structs in a file, motion types and structs in another, perhaps an entire separate one for cylinder types and motions?)
• Combine IBmodel and IBproblem?
• Possible renaming: AbstractIBProblem --> AbstractProblem, IBProblem --> Problem, State --> AbstractState --> IBState --> State

[jcallaham]

For IBModel vs IBProblem - I set it up this way as kind of a half-baked compromise between the "NavierStokesModel" in the C++ code and the "Problem" interface for DifferentialEquations.jl. Basically the idea was to try to contain the physical setup (compressibility/viscous, etc) in the "model" and do the time evolution with "problem". But now that I understand the methods a bit better I think the treatment of different physics might be too different to be conveniently abstracted like this. Also so far nobody has mentioned interest in doing anything but incompressible viscous flow, so maybe it's not worth worrying about too much.

In other words, at the moment there's no clear conceptual distinction to me between what should be at the "model" vs "problem" level, but I can't tell whether or not that would change with likely future work. Any thoughts?

[ajgoza]

I see the distinction you're drawing now. I agree with your assessments that (i) the distinction is not especially necessary now, and (ii) it might be useful depending on changes we make moving forward. Let's chat more tomorrow