You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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.
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?
The text was updated successfully, but these errors were encountered: