Trailing OPTIONS block in model name file

[mjreno]

Version: Commit d50342f
Recreate:

• Run test_component.py quickstart test and inspect mymodel.nam

Result mymodel.nam:

BEGIN PACKAGES
 DIS6 mymodel.dis dis
 IC6 mymodel.ic ic
 OC6 mymodel.oc oc
 NPF6 mymodel.npf npf
 CHD6 mymodel.chd chd0


END PACKAGES

BEGIN OPTIONS
END OPTIONS

[wpbonelli]

copying comment from #230, I guess in general we want to omit empty blocks. And I also thought we could assume the order the writer processes blocks in would match the DFN block definition order but evidently not.

[mjreno]

I think in general we don't want to omit empty blocks unless the blocks themselves are optional.

[wpbonelli]

I didn't realize that was a distinction- ok so some blocks need to be written even with nothing inside.

[mjreno]

This probably deserves another look- how it is specified and enforced. For now I think we always want to write OPTIONS blocks even if empty. mf6io will refer to other cases- e.g. DISU VERTICES and CELL2D are expected only if the dimension NVERT is defined. There are other special cases. isn't RELEASTIMES in PRP one? CSUB packagedata I think.

[wpbonelli]

RELEASETIMES is optional, it's only required if you specify a positive NRELEASETIMES in the dimensions block.

But in any case agreed- I guess there are 2 problems, ordering (options should come first) and configuring some blocks to get written even if they're empty.

The spec defines blocks minimally as dicts of fields. I was hoping we could stick with that and not have to give them any extra attributes. But we need to know at least

• whether they are required (should be written regardless of contents)
• whether they should be sliced on a particular dimension and indexed, like period blocks

You could argue this a writer-specific concern? Say MF6 got the ability to load yaml/toml/json files and relaxed the requirement for empty blocks in those, and kept it in the existing ascii format to avoid changing the block parser.

That way the spec and the generated classes can stay simple, and only a format-specific converter would have to know these block options, the writer could ideally stay ignorant of them too?