Behaviour when no compartments are defined

[jan-stevens]

For basic packing functionality, it would be handy if we could also pack systems without defining a compartment. Currently this throws an error.

I think the ideal behavior should be:

• no compartments defined in the space: Simply pack all segments in the cuboid defined by space[size].
• compartments defined in the space: Current behavior.

This would make it simpler to pack cubic cytoplasms without having to define a "main" compartment. (this seems a bit convoluted?)

[ma3ke]

I agree that it would be nice to be able to omit the compartment definition.

That does leave the question of defining what compartment a segment belongs to in the "segments" section. Should that default just be called “main” implicitly? Or should an empty/unset compartments field for a segment imply the unset main compartment.

Setting a default compartment is a trivial change but it will only improve the interface if the segment definitions still make sense.

What do you think would be the neatest way of doing that?

[jan-stevens]

I think the easiest way to do this is to always create an implicit 'main' compartment at the start of our routine, which is just the box dimensions. Every segment is then, by default, part of this 'main' compartment.

I'm not sure if this will significantly impact performance. I imagine that having this extra compartment/mask will be noticeable for very large systems. Is this a problem?

[ma3ke]

The performance matters are not the concern here, in my initial estimate :)

What does slightly worry me is the confusion that comes from a default compartment. But if we do it like you propose, I think, such that

• if left unspecified, there is one compartment called “main” with a cuboid shape
• if left unspecified, each compartment has one compartment id in its list, which is “main”, but only if the compartment is not specified either

In case the compartment is specified, the implicit default for the segment compartment ids are not valid, and throws a good error about it.

That is all to prevent the following scenario: a specific (set of) compartment(s) is specified yet no segment has any compartment ids. That empty result would be very confusing otherwise.

[ma3ke]

If you do not set compartments in the space section, but do provide the compartments field in any of the segments in the segments section, you get the following error:

            If no `compartments` are defined in the `space` section,
            compartment selections in segment definitions are not allowed.
            When no compartments are defined in the `space` section, a single
            default compartment is implied. To set each segment's compartment
            to the implied default compartment, remove the `compartments`
            field from all segment definitions.

Though a bit wordy, I do think it communicates what is going on.

With this error in place, I'm comfortable moving forward with implementing this. Almost done :)

[ma3ke]

@jan-stevens, please let me know if you find these changes to your liking and that they properly reflect your suggestion.

Especially the note in the README (4673fca) about these defaults.

Something I am not entirely certain about is the following: currently, when any compertment is defined in the space section, a segment can have a compartments field, or omit the field. When it is omitted, a segment is understood to be in the implied "main" compartment, regardless of whether any compartment is actually called "main" or not. If this is considered problematic, there are at least two possible ways to improve this:

• If any compartments are set in the space section, all segments must have a compartments field set as well.
• If any compartments are set in the space section, segments may have a compartments field set, and their contents are checked to be valid references into the compartments set in the space section.
  • We can also make this idea into a new issue and come around to that at some point independent from the current change. It would be more like an addition onto the present changes.

If everything looks good we can merge the PR, I think.