schema for core input file

2012-11-09
2013-03-16
  • Is there a schema, preferably as xsd, for the built-in types of the input file?  I can generate the xsd for the modules, such as powerflow, but this then has restrictions which are not defined in that xsd and refer to core elements of GridLAB-D, such as xs:int64 or xs:object.  for example:

    <?xml version="1.0" encoding="utf-8"?>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.w3.org/" xmlns="http://www.w3.org/" elementFormDefault="qualified">

    <xs:element name="powerflow_object">
    <xs:complexType>
    <xs:all>
    <xs:element name="id">
    <xs:simpleType>
    <xs:restriction base="xs:int64"/>
    </xs:simpleType>
    </xs:element>
    <xs:element name="parent">
    <xs:simpleType>
    <xs:restriction base="xs:object"/>
    </xs:simpleType>
    </xs:element>

    </xs:all>
    </xs:complexType>
    </xs:element>

    I'm trying to translate from MultiSpeak to GridLAB-D's input format, using Altova's MapForce which can take XSD's (and other types) as inputs and facilitates mapping from one format to another.  It will be a lot easier if I can feed in a set of XSD's which correspond to GridLAB-D's structure.  Once I can output as XML, I can translate that to GLM if needed.  The set of mostly non-standard xsd restriction types which are referred to by the powerflow xsd are:

    xs:bool
    xs:char1024
    xs:char256
    xs:char32
    xs:complex
    xs:datetime
    xs:double
    xs:enumeration
    xs:int16
    xs:int32
    xs:int64
    xs:latitude
    xs:longitude
    xs:object
    xs:set
    xs:timestamp

    Thank you for any help,
    Cedric

     
  • Jason Fuller
    Jason Fuller
    2012-11-12

    Cedric,

    We have <some> of what you are asking for, but its been a while since we've looked at it closely.  We have someone looking over it now and will get back to you ASAP.

    Jason

     
  • Thank you, I look forward to it.  Any thing will help.

    Cedric

     
  • I have found a reference for what we should do to fix this.  Which version do you want this in?  Normally I prefer to introduce things in trunk, but this is benign enough that I could introduced in 2.3 without much difficulty.

     
  • 2.3 would be great, but if trunk is stable enough, I suppose that would be fine as well.  (I suppose trunk is work in progress towards 3.0?)

    With your fix, would it be that the -xsd option would generate a complete xsd without references to external resources, or how would it work?

    I am not sure how to install 2.3 or trunk to windows.

    I readily found a windows executable installer for 2.2, but my client would likely benefit from 2.3's (grizzly's) handling of distributed generation (i.e. solar).  Are there windows installers for 2.3 or the trunk (3.0?), or do I need to download a GNU tarball from one of the following locations and make/install from that?
        http://gridlab-d.svn.sourceforge.net/viewvc/gridlab-d/branch/2.3/
        http://gridlab-d.svn.sourceforge.net/viewvc/gridlab-d/trunk/

    If I need to make/install, I haven't yet found a page or document with instructions on how to do so, though presumably a search of the forum would uncover that information…

    Thank you again,
    Cedric

     
  • for executable installers, I found a reference to https://sourceforge.net/projects/gridlab-d/files/gridlab-d/ containing stable builds, nightly releases, etc.  I suppose if you add your changes to 2.3 or to trunk, they may soon appear in the nightly releases folder?

    -Cedric

     
  • I will try to post a fix to trunk tonight. Let me know if its ok and then I'll update 2.3.

     
  • Jason Fuller
    Jason Fuller
    2012-11-14

    Dave,

    I think for this change, it would be fine in v23 - its relatively minor.

    Cedric,

    The new version will only post to the stable builds folder if the updated changes pass all of our validation tests (this will definitely not be true in the trunk, but should post in the branch versions).  You can tell whether it did by the date attached to that file.  If not, you'll need to actually download the source code and perform a manual build.

     
  • I posted the new restrictions to trunk a few minutes ago.  Let me know if they work and we can copy them to 2.3 when you confirm they work ok.

     
  • Thanks.  I'm having trouble building on Windows 7 64-bit machine, so I haven't been able to test the changes.  Looking at the changes I am not sure they directly address some of the external restriction references, e.g. xs:object:
    <xs:element name="parent">
    <xs:simpleType>
    <xs:restriction base="xs:object"/>
    </xs:simpleType>
    </xs:element>

    However, one of the two changed files, core/property.c, makes me think that I could replace the xs:object restriction with xs:string.  If so, that is also a helpful find.

    Regarding difficulties building, in VS2005, the two most common errors are that the windows.h and winsock2.h files are included by several files but do not exist in the directory tree.

    (By the way, VS2005 reports that it has known compatibility issues with my system, so I tried with VS2012 but that was an ugly can of worms, so I then proceeded with 2005 despite the warning.)

    Thanks again,
    Cedric

     
  • Thank you again for your help.  Though I haven't been able to compile yet (due to the aforementioned missing .h files), your changes and the files you changed contained crucial information.  I modified the powerflow module's output xsd to replace the custom constraint types with appropriate standard types.  I also added a "BogusRootElement" to the XSD because Altova's MapForce tool required that I select a root element.  I am now able to start mapping from MultiSpeak to an appropriate input format for GridLAB-D.

    I appreciate you and your DOE funders!
    Cedric

     
  • If you can email me both the glm and the XML files I can make the changes needed to both versions.

     
  • I looked at core/output.c:ouput_xsd().  It is using <xs:schema> as a root element.  Are you asking that we create a root element outside or inside that one?  Could you send me an example of the XSD that works so I can make the function work the same way?

     
  • Hi David.  Actually, my problem was not that the powerflow XSD itself lacked a root element, but that an instance matching its specification would lack a root element.  Initially I added a root element called <BogusRootElement>, but later I saw an example of an input file which had a root element called <gridlabd>, so I used that name instead.

    (I'll follow the convention of W3C schema documentation, where an element is delimited like <this>, and an element's properties/contents are delimited by {curly_braces}.)

    Another issue I discovered was that the contents of many of the nodes did not match the descriptions at Power_Flow_User_Guide .  Namely, it looks that the elements are not structured to inherit the properties of what should be their parent types.  For instance, a <line> is a type of <link>, and as such should have {from} and {to} properties, but the xsd did not list those for <line>.

    I finally bit the bullet and combed through the powerflow XSD and implemented the proper inheritance relationships as specified in the User Guide.

    There are some fields specified in the User Guide (like {name} for all objects, and {reference_phase} for <substation>), which I added because I need them and noticed they were missing.  I have not verified that all of the fields listed for the elements in the User Guide are in fact in my new XSD, I think at least my version should be more and not less complete than the originally output XSD.

    I'm not sure how to attach or send my file, and apparently my text looks like a comical meat product and won't be posted.  How do I send you or attach a file?

     
  • Another try to paste in a code sample:

    <?xml version="1.0" encoding="utf-8"?>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.w3.org/" xmlns="http://www.w3.org/" elementFormDefault="qualified">
    <xs:element name="gridlabd" type="gridlabd"/>
        <xs:complexType name="gridlabd">
            <xs:choice minOccurs="0" maxOccurs="unbounded">
                <xs:element name="powerflow_object"  type="powerflow_object_Type"/>
                <xs:element name="powerflow_library" type="powerflow_library_Type"/>
                <xs:element name="node" type="node_Type"/>
                <xs:element name="link" type="link_Type"/>
                <!-- ... -->
            </xs:choice>
        </xs:complexType>
        <xs:complexType name="powerflow_library_Type">
            <xs:sequence>
                <xs:element name="id" minOccurs="0">
                    <xs:simpleType>
                        <xs:restriction base="xs:long"/> <!-- was xs:int64 -->
                    </xs:simpleType>
                </xs:element>
                <xs:element name="name" minOccurs="0"> <!-- Added by CdLB -->
                    <xs:simpleType>
                        <xs:restriction base="xs:string"/>
                    </xs:simpleType>
                </xs:element>
                <xs:element name="parent" minOccurs="0">
                    <xs:simpleType>
                        <xs:restriction base="xs:string"/> <!-- was xs:object -->
                    </xs:simpleType>
                </xs:element>
                <!-- ... -->
            </xs:sequence>
        </xs:complexType>
    
        <xs:complexType name="powerflow_object_Type">
            <xs:complexContent>
                <xs:extension base="powerflow_library_Type">
                    <xs:sequence>
                        <xs:element name="phases" minOccurs="0">
                            <xs:simpleType>
                                <xs:restriction base="xs:string"> <!-- was xs:set -->
                                <xs:pattern value="A|B|C|D|N|S|G"/>
                                </xs:restriction>
                            </xs:simpleType>
                        </xs:element>
                        <xs:element name="nominal_voltage" type="xs:string" minOccurs="0"/>
                    </xs:sequence>
                </xs:extension>
            </xs:complexContent>
        </xs:complexType>
        <!-- ... -->
    </xs:schema>
    
     
  • Perhaps the easiest thing to do is create a TRAC ticket describing the specific change you are requesting.  You can attach example files, etc. to that ticket.