As a continuation of what was begun, several features have taken a slight departure from the original design of Plexus. The first being how data is exported and passed on to the next component, usually the solver, in the tool-chain. Another feature is the domain and property information required by a team in the pre-processing of data.

The first feature change is in how Plexus transports data to the next phase. Elemental data to include user defined properties are normally saved to a file for consumption by the next phase in the users tool chain. The issue at hand is that practically everyone is using a unique file format making the exporting of the models’ data a very repetitive and time consuming development process.

To that end, the initial approach decided upon is to store this data in a database and let the user choose what data is exported and how the data is ordered in such a way that matches the required input format and not be a tedious process. Some sort of high-level scripted template type adaptor will be used to allow for easier customization of the users input deck. I say initial because another programmatic type interface is planned way down the road for a more integrated and efficient method for transporting data over the network. This is where the majority of work will be focused in the time allotted for the next several months.

As to the latter, and more minor, change in progress, many of the user defined properties are not required by all users, so while the properties will be available, they will not be displayed unless chosen. This seems like an obvious choice to make on the surface, but many of these properties are heavily integrated within the UI and therefore, this too will be more generalized.

As always, feel free to send feedback or ask questions.

grobe

Plexus3D developer.