How to pass a problem definition?

[keileg]

In the API, how is the problem definition communicated? I am thinking of specification of the governing equation, domain geometry, possibly grid specification, and parameter definition. On a conceptual level, this can either be decided up front (and passed to the init of solver), or passed as a Parameter to the several methods. The former option will imply that the API in a certain sense is incomplete, while under the latter, reuse of discretization under subsequent calls will require checks that the problem parameters have not changed.

Related, have you decided on a format on specifying the problem, or is the plan to build a protocol for this as we move along?

[TheBB]

Currently we are specifying the problem simply by passing an IFEM input file path to the constructor of our subclass of PhysicsModel. E.g. here:

Costa/test/ifem-heateqn/test.py

Line 13 in bc6fb7d

pbm = Ifem.HeatEquation('square.xinp')

where Ifem.HeatEquation is a class that exports an interface compatible with Costa.api.PhysicsModel.

The square.xinp file has info about geometry, topology, discretization, boundary conditions and source terms. It also has timestepping info, but that isn't actually used (the timestep is passed as a parameter e.g. to pbm.predict()).

Formalizing such specification was intentionally left blank for the moment, and I'm not sure how far we want to go there.

[keileg]

It all makes sense, including how the problem definition is specified. Thanks.

FYI: I have implemented a finite volume-based physics-based model as an alternative to the Ifem solver, with everything running smoothly once I had removed all the bugs on my side. We can discuss on Wednesday.