[SSP] Support multi-step-size configuration

[markaren]

I'd like to add support for multi-step-size configurations also when using SSP.

The XML could look something like:

<ssd:DefaultExperiment>
        <ssd:Annotations>
            <ssc:Annotation type="com.opensimulationplatform">
                <osp:Algorithm>
                   <osp:FixedStepAlgorithm baseStepSize="1e-4">
                       <osp:StepSizes>
                            <osp:StepSize component="KnuckleBoomCrane" multipleOf="2"/>
                       </osp:StepSizes>
                   </osp:FixedStepAlgorithm>
                </osp:Algorithm>
            </ssc:Annotation>
        </ssd:Annotations>
    </ssd:DefaultExperiment>

This uses the suggested XML change proposed in #426

The xsd for this looks like

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
           targetNamespace="http://opensimulationplatform.com/SSP/OSPAnnotations"
           xmlns:osp="http://opensimulationplatform.com/MSMI/OSPModelDescription">

    <xs:element name="Algorithm">
        <xs:complexType>
            <xs:sequence>
                <xs:any processContents="skip"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

    <xs:element name="FixedStepAlgorithm">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="StepSizes" type="StepSizes"/>
            </xs:sequence>
            <xs:attribute name="baseStepSize" type="xs:double" use="required"/>
        </xs:complexType>
    </xs:element>

    <xs:complexType name="StepSizes">
        <xs:sequence>
            <xs:element name="StepSize" maxOccurs="unbounded">
                <xs:complexType>
                    <xs:attribute name="component" type="xs:string" use="required"/>
                    <xs:attribute name="multipleOf" type="xs:unsignedInt" use="required"/>
                </xs:complexType>
            </xs:element>
        </xs:sequence>
    </xs:complexType>

</xs:schema>

Note that the xsd is not tied to a particular Algorithm. The multiple step-size configuration is tied directly against the osp:FixedStepAlgorithm element.

[markaren]

Some brainstorming is required to figure out how to best go about this. Ideally we need to implement a plugin based system. This should be synchronized with the cse_config_parser as there is no reason why we could not use the exact same C++ and XML code for this. However the cse_config would need to copy this structure (since this is algorithm agnostic and extensible).

[markaren]

This PR also relates to #427

[markaren]

The following is a prototype of a plugin solution for parsing the algorithms.

std::unique_ptr<cse::algorithm> fixed_step_algorithm_parser::parse(const boost::property_tree::ptree& tree) {
    
    for (const auto& node : tree) {
        if (node.first == "osp:FixedStepAlgorithm") {
            auto stepSize = get_attribute<double>(node.second, "stepSize");
            std::unique_ptr<cse::algorithm> algorithm = std::make_unique<cse::fixed_step_algorithm>(stepSize);
            
            if (const auto stepSizes = tree.get_child_optional("osp:StepSizes")) {
                for (const auto& stepSizeNode : *stepSizes) {
                    auto component = get_attribute<std::string>(stepSizeNode.second, "component");
                    auto multipleOf = get_attribute<unsigned int>(stepSizeNode.second, "multipleOf");
                }
            }
            
            return algorithm;
            
        }
    }

    return nullptr;
    
}

This particular code is able to create afixed_step_algorithm and has access to information about the decimation_factor for sub-simulators. HOWEVER, it cannot act on it since simulators has to be added before set_stepsize_decimation_factor can be invoked. Any ideas?

[eidekrist]

I have a suspicion that this will be easier to implement once PR #427 is merged, where the flow is:

1. parse info from files.
2. validate info.
3. create actual things from info.

This means your above code could create something like a fixed_step_algorithm_info, where all relevant data is stored and at a later point is applied to create a fixed_step_algorithm and set decimation factors etc.

[markaren]

I fear #427 is becoming a chicken and the egg thing right now. #427 won't work if the ssp parser and cse parser is doing wildly different things.

[kyllingstad]

In case it was unclear: #427 is by no means complete. I posted it as a request for comments, not as a finished solution. I've just been completely swamped with other work in the past two weeks and haven't had a chance to follow up and complete it yet.

#427 won't work if the ssp parser and cse parser is doing wildly different things.

Once the system_structure functionality is in place, the only responsibility left to the CSE/SSP parsers will be to parse the XML files and convert the information in them to system_structure objects. As long as system_structure is able to hold the same information as any CSE/SSP XML file, then it's given that it will work, regardless of how differently the parsers go about that task, and regardless of how different the XML data structure is to the internal system_structure data structure. That's the beauty of separation of concerns. :)