Allow customization of standard resource containers (CTBs, etc) using input files.

Currently, the auto-manifesting process does not consider mass of newly-generated resources (e.g., waste or ISRU) when evaluating mass/volume constraints on supply edges, resulting in some infeasible manifests which create errors during simulation.

Currently, the resource property type refers to the resource type. Change it to resource to be more descriptive.

Implement the logic that allows instances of element templates to override the specified states, parts, contents from the template.

Demand models can reference custom resource types, so assign IDs to resource types prior to serializing the demand models.

Upon loading a saved scenario that has volume constraints enabled, the auto-manifesting process does not appear to adhere to volume constraints. However, after opening and closing the options dialog, the volume constraints appear to be enforced.

The GUI presents Health Consumables as a demand rate (kg/crew/day); however, the implementation treats it as a demand amount (kg/crew). This appears to be a problem with the implementation as the SpaceNet 1.3 user's guide includes the CHeCSConsumables (Crew Health and Care System Consumables) as a demand rate.

Allow rated and impulse demand model instances in JSON to override template values of demands and demandRates (respectively).

Demand model has a reference to the parent element which breaks when reloading instantiated elements (reference points to a template element rather than the instantiated element in a scenario.

1. When saving new scenario to JSON, no content is written to file.
2. When saving a scenario having (in-memory) element templates but no instantiated elements to JSON, no element templates are saved.
3. When editing a scenario having (in-memory) element templates, instantiated elements reference the templates rather than creating a new instance.

Raw Capacity, Remaining Capacity, and Estimated Demands may not be the best labels to explain feasibility prior to manifesting. Consider alternatives?

I noticed that SpaceNet Java, when reading a JSON scenario file, seems to change the scenario start date/time by 5 hours. If the start date in JSON, for example, 2030-01-01T00:00:00.000000+00:00, then the date becomes Dec 31, 2029 instead of Jan 1, 2030. However, if the JSON date is 2030-01-01T05:00:00.000000+00:00 (i.e., 5 hours ahead), then the SpaceNet Java date becomes Jan 1, 2030. There is probably a time zone problem.

Prior changes counted element mass against flight transport capacity, so crew mass should be considered in mass constraints.

Use CTBE parameters outlined in:

Goodliff, K. E., Stromgren, C., Dickert, Z., Ewert, M. K., Hill, J., & Moore, C. (2017). Logistics needs for future human exploration beyond low Earth orbit. AIAA SPACE and Astronautics Forum and Exposition. https://doi.org/10.2514/6.2017-5122

When reloading instantiated elements from a data source, some states appear to be duplicated.

Rename the event type ReconfigureGroup to ReconfigureElements in JSON scenario serialization.

Rename as follows:

• crew consumables: "CrewConsumables"
• timed impulse: "TimedImpulse"
• rated: "Rated"
• sparing by mass: "SparingByMass"

Add ability to export the full simulation state trajectory to file, similar to the demands analysis.

By default, demands for generic resources (e.g., from the consumables demand model) only generate unpressurized demands. This assumption aligns also with the default resource containers which only hold unpressurized resources. Consider adding the ability to customize the default resource environment to more accurately represent the nature of most demands.

Generic resources default to unpressurized environment and cannot be changed in the GUI table presentation.

Interest to understand and track the "supply edge" cargo capacity (mass and volume) post-manifesting.

Currently, there is no feedback if a user tries to add an incompatible resource (e.g., pressurized resource to unpressurized environment) to a resource container via the edit element dialog. It appears to work, but then does not save properly. Add some feedback to alert for incompatible resources.

The sparing-by-mass demand model assumes 365 days per year for computing spares demands; however, the dialog box shows estimated demands assuming 365.25 days in a year. Correct the dialog box to align with the underlying demand model behavior.

Generic resources currently have the following hard-coded unit volumes:

• COS 1: 1900 cm^3/kg
• COS 201: 1000 cm^3/kg
• COS 2: 7000 cm^3/kg
• COS 3: 5000 cm^3/kg
• COS 4: 3000 cm^3/kg
• COS 5: 7000 cm^3/kg
• COS 6: 5000 cm^3/kg
• COS 7: 5000 cm^3/kg
• COS 8: 3500 cm^3/kg
• COS 9: 3500 cm^3/kg
• COS 10: 7000 cm^3/kg
  It would make sense to allow them to be user-editable, for example, to reflect resource innovation.

Currently, the mission duration is determined by slicing the entire scenario timeline and allocating to individual missions. However, this does not align with an intuitive assumption if there are intermediate missions, e.g., cargo resupply, during a longer crewed period. Consider making each mission duration the time between the first event start and last event end to help align with mission-level demand models based on time.

When converting from XML to JSON serialization, the properties of instantiated element-level demand models are receiving a demandRates property with an empty list, overriding the default demand model properties.

Add another headless functionality into the Java code that would, apart from computing demands, also run the Auto-Manifest algorithm and return the resulting manifest. If it is too cumbersome to have a separate JSON structure for the manifest, it can be returned in the same text format it is now exported in in the GUI (the Export Manifest block on the Manifest tab).

Also, I noticed that the Export Manifest block currently exports only items that were manifested but does not export any details for items that were packed but failed to be manifested. If it is not difficult, can those be extracted as well for the headless functionality? Either within the same manifest structure (e.g., with the flight ids empty) or as a separate block of data - whatever is simpler.

Any interaction with an Excel database results in the following:

Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: Could not initialize class org.apache.poi.hssf.usermodel.HSSFWorkbook

1. In-memory data source dialog adds new instances rather than editing existing ones

The GUI shows a bug when a new flight transport is added immediately after a flight transport that terminates at an Earth surface destination (probably because there are no flight transports with that node as an origin). Can be recreated in quick start scenario 2 by adding a flight transport event after the Earth return flight in either crewed mission.

Allow user-customizable configuration of default packing factors for generic COS used during demands analysis (pre-manifesting).