MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "ReverseLoad_Custom_Task",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "126": {
                "pageid": 126,
                "ns": 0,
                "title": "Reading Material Points from a Previous Simulation",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "Sometimes it is useful to run a simulation, output the material point locations, and them use those settings for a new MPM simulation. One approach is to extract all material point locations to an <tt>XML</tt> file using the [[ExtractMPM]] tool, and then input that file to a new commands file. The process is:\n\n<ol>\n\n<li>Run an MPM simulation\n\n<li>Select an archive time and use [[ExtractMPM]] to extract particle data to an XML file. A typical command would be:\n\n<pre>ExtractMPM -Xh -q mass -o particles Archive.1843\n</pre>\n\nwhere <tt>Archive.1843</tt> is desired time archive containing material point locations. The points will be written to an <tt>XML</tt> file called <tt>particles.xml</tt>. The output file will have one [[PointList Block|<tt><PointList></tt> block]] with one<tt><mp></tt>element for each material point. See the [[ExtractMPM]] tool documentation for more details on an XML extraction.</li>\n\n<li>Finally, include this saved file in another commands file using an <tt>XML</tt> entity reference. First, define the path to the new file using an [[Entity Command|<tt>Entity</tt> command]] such as:\n\n<pre>Entity mpfile,particles.xml\n</pre>\n\nwhere its value is a relative path to the file with the particle locations. In <tt>XML</tt> files, the entity is defined in the file's <tt>DOCTYPE</tt> element such as:\n\n<pre>&lt;!DOCTYPE JANFEAInput SYSTEM '/full path to/NairnMPM.dtd'\n[   &lt;!ENTITY mpfile SYSTEM \"pointlist.xml\"&gt;\n]&gt;\n</pre>\n\nSecon, include that file in the section that defines material points using and [[XMLData Command|<tt>XMLData</tt> command]] such as:\n<pre>XMLData,MaterialPoints\n   &amp;mpfile;\nEndXMLData\n</pre>\n\nIn <tt>XML</tt> files, the file is include in the <tt><MaterialPoints></tt> element using\n\n<pre>&lt;MaterialPoints&gt;\n   &amp;mpfile;\n&lt;/MaterialPoints&gt;</pre>\n\n</ol>"
                    }
                ]
            },
            "69": {
                "pageid": 69,
                "ns": 0,
                "title": "Resequence Command",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "The <tt>Resequence</tt> command is used to renumber the numbers in an attempt to minimize the bandwidth of the problem. The smaller the bandwidth, the faster will be the FEA calculations.\n\n== Scripted Input Files ==\n\nThe two options in scripted input files are\n\t\n Resequence (x),(y)\n\nor\n\t\n Resequence (id)\n\nwhere\n\n* (<tt>x</tt>, <tt>y</tt>) define the coordinates (in [[ConsistentUnits Command#Legacy and Consistent Units|length units]]) for a point (or <tt>(R,Z)</tt> coordinates if axisymmetric). The resequencing will start at the one node nearest to that point.\n* <tt>(id)</tt> is a previously defined [[Keypoint Command|keypoint]]. The resequencing will start at the node at that keypoint.\n\n== XML Input Files ==\n\nIn <tt>XML</tt> files, the two options are:\n\n <Resequence x='(x)' y='(y)'/>\n\nor\n\t\n <Resequence keypt='(id)'/>\n\nwhere <tt>(x)</tt>, <tt>(y)</tt>, and <tt>(id)</tt> are the same as defined [[#Scripted Input Files|above]]. Whichever method is used, it must be the ''last'' command in the single [[FEA Boundary Conditions#XML Input Files|<tt><GridBCs></tt> block]] in the file.\n\n== Notes ==\n\nThe resequencing is done using the \"GPS Algorithm, named after Gibbs, Poole, and Stockmeyer (1976).<ref name='RS'>N. E. Gibbs, W. G. Poole, and P. K. Stockmeyer, \"An Algorithm for Reducing the Bandwidth and Profile of a Sparse Matrix,\" <i>SIAM Journal of Numerical Analysis</i>, <b>13</b>, 236-250 (1976).</ref> Another bandwidth minimization method is the RCM method or the Reverse Cuthill-McKee method.<ref name=\"RCM\">E. Cuthill and J. McKee. \"Reducing the bandwidth of sparse symmetric matrices,\" In Proc. 24th Nat. Conf. ACM, 157\u2013172 (1969).</ref> No method gets the absolute minimum. In testing, GPS and RCM get similar results but GPS is faster.\n\n# It is best to start the resequencing at a node on the boundary of the object and probably on a corner. The final bandwidth may depend on the node selected for resequencing. The bandwidth is reported in FEA output results. You can vary the resequencing node to find the minimum value.\n# Another use of this command is to verify mesh connectivity. Since disconnected sections of a static FEA mesh will cause a singular stiffness matrix, the calculations will fail. If you use a <tt>Resequence</tt> command on a disconnected mesh, it will detect the problem and abort the calculations.\n\n== References ==\n<references/>"
                    }
                ]
            }
        }
    }
}