MARBL is not a Component

[dafyddstephenson]

There are some fundamental issues with C-Star's design, many of which come from treating MARBL and ROMS as Component subclasses.
The design of the Component base class is reasonable. It is fair to assume that to run a specific instance of any Earth (sub)system model, one would need:

• A base model
• Model discretization information
• Input datasets
• Namelist files (runtime code)
• Additional source code files (compile-time code)

The requirements of most ESMs resemble this, and they can run independently of being coupled into a greater system. MARBL cannot run independently of being coupled to another component, and thus most of the items in the above list make no sense as belonging to a MARBLComponent instance. This forces us to create a vary weak base class with most of these things missing, in order to accommodate this weird case in which they don't make sense. In fact, these attributes do make sense, and what makes no sense is treating MARBL as a "Component" (a term that we never rigorously defined).

I would instead call it an ExternalLibrary or something similar and use it as another attribute of a ROMSComponent instance. The "problem" that results from this is that C-Star will then consist of a single Component subclass until it is expanded to accommodate another model.

[TomNicholas]

This is a really good point, and I think something we potentially discussed briefly right at the start.

Is there anything that an ExternalLibrary (I think we can come up with a better name than this) and a true Component do share? AdditionalCode perhaps?

The "problem" that results from this is that C-Star will then consist of a single Component subclass until it is expanded to accommodate another model.

This is not the worst thing in the world, if it forces us to be clearer about our interfaces and responsibilities.

[dafyddstephenson]

The MARBLComponent subclass currently requires a BaseModel instance and optionally allows additional_source_code (following #117 ). Namelists don't make any sense as a MARBL attribute, as all runtime i/o (including parsing settings files) is managed by the parent model. As for additional_source_code , any invocation of this currently raises a NotImplementedError, but I can't imagine this ever gets used: MARBL is more of a one-and-done compile and prides itself on runtime customisability. Anybody wanting to mess with the source code is almost certainly an advanced enough user to use a custom fork as the base model.

[dafyddstephenson]

I think there's a discussion to be had even about whether MARBL even corresponds to an object in C-Star. It very much is an external library to ROMS, and could be seen as an optional dependency of ROMS in the same way an MPI library could, the only difference being that a vanishingly small number of users will run ROMS in serial, but a large number will run it without MARBL.