Anonymous
×
Create a new article
Write your page title here:
We currently have 105 articles on MOR Wiki. Type your article name above or click on one of the titles below and start writing!



MOR Wiki
MOR Wiki
105Articles
  Recent changes

The MORWiki benchmark collection contains benchmarks related to model order reduction. Its goal is to supply dynamical systems in a computer-readable format to researchers from different areas, who can then test new algorithms, software, etc.

The collection contains documents and wikipages that are human-readable and data files that can be read automatically by software. As a result, with minor exceptions, the rules concerning page preparation are recommended, while those concerning data files are considered obligatory (with exceptions, for example, for new types of nonlinear models).

1 Benchmark Creation

Anyone who has an example that could be relevant for the benchmark collection can add it after the editors have approved it. Simply write an email to the editors describing the benchmark to be created. Ideally, one should be able to point to an existing data set and publication. If the editors accept the benchmark, they then grant access to the submitter and create an empty page for the benchmark, which the submitter must then edit with a description of the benchmark, uploaded data files, and any supplementary documents, all of which should be linked within the page itself. See 2.1 for the content requirement.

2 Content Rules

The supplementary documents as well as the wikipage may be written by different authors, however each individual document should be written according to conventional scientific practice; that is, it should describe the subject in such a way that, at least in principle, anyone could reproduce the results presented. The authors should understand that the document may be read by people from quite different disciplines. Hence, abbreviations should be avoided or at least explained and references to the background ideas should be provided.

2.1 Page Name

Be careful to choose a unique, concise name, around 2-3 words. This name will become a permanent attribute of the benchmark and will be used internally for downstream purposes.

2.2 Content Requirement

Most of this content can be included in the wiki page directly. However, this is not necessary. One should describe the origin of the dynamical system and its relevance to the application area. It is important to present the mathematical model, the meaning of the inputs and outputs, and the desired behavior from the application viewpoint.

The following points should be considered and if possible included in the benchmark description:

  • The purpose of the model should be explained clearly. (For instance, simulation, iterative system design, feedback control design, ...)
  • Why should the model be reduced at all? (For instance, reducing simulation time, reducing implementation effort in observers, controllers...)
  • What are the QUALITATIVE requirements to the reduced model? What variables are to be approximated well? Is the step response to be approximated or is it the Bode plot? What are typical input signals? (Some systems are driven by a step function and nothing else, others are driven by a wide variety of input signals, others are used in closed loops and can cause instabilities, although being stable themselves.)
  • What are the QUANTITATIVE requirements to the reduced model? Best would be if the authors of any individual model can suggest some cost functions (performance indices) to be used for the comparison. These can be in time domain, or in frequency domain (including bandwidth), or both.
  • Are there limits of input and state variables known? (application related or generally)? What are the physical limits where the model becomes useless/false? If known a-priori: Out of the technically typical input signals, which one will cause "the most nonlinear" behavior?
  • How many parameters are included in the model, are they physical parameters or geometrical parameters.
  • Is the system linear or nonlinear? Is it a first or a second order system?
  • When the model is used to test, e.g. an algorithm, can some of the parameters in the model be fixed, such that the model includes fewer parameters, which makes the testing easier?
  • If possible, the source code generating the model should be provided.
  • We stress the importance of describing the software employed, as well as its related options. For example, if the model is generated from ANSYS, the software ANSYS better be mentioned. If necessary, please also describe some related options like boundary conditions, initial conditions, and other parameters which need to be assigned when generating the model. Please go to the benchmark webpage Silicon nitride membrane for a reference.
  • If the dynamical system is obtained from partial differential equations, then the information about material properties, geometrical data, and initial and boundary conditions should be given. The exception to this rule is the case when the original model comes from industry. In this case, if trade secrets are tied with the information mentioned, it may be kept hidden.
  • The authors are encouraged to produce several dynamical models of different dimensions in order to provide an opportunity to apply different software and to research scalability issues. If an author has an interactive page on their server to generate benchmarks, a link to this page is welcome.
  • The dynamical system may be obtained by means of compound matrices, for example, when the second-order system is converted to first-order. In this case, the document should describe such a transformation but in the data file the original and not the compound matrices should be given. This allows for researching other ways of model reduction of the original system.

The above information is in a general sense. Therefore, some items may not be applicable to certain benchmarks. However, it is recommended that the items that apply to the benchmark provided be fully considered.

2.3 Additional Content

This will typically be given in form of a document which we restrict to the following types: *.pdf, *.gif, *.jpeg, *.jpg, *.png,. This documents should include author names.

  1. The solution of the original benchmark that contains sample outputs for the usual input signals. Plots and numerical values of time and frequency response. Eigenvalues and eigenvectors, singular values, poles, zeros, etc.
  2. Model reduction and its results as compared to the original system.
  3. Description of any other related results.
  4. We stress the importance of describing the software employed as well as its related options.

2.4 Metadata

To aid in the categorization of benchmarks, we request that submitters provide the following information explicitly:

  • List of author names in Last, F. format
  • Citation in standard format
  • License (see, e.g., https://tldrlegal.com/)
  • Model components (which should match what is submitted in the data file(s))
  • Differentiation index of DAE: 0, 1, 2, etc. (0 indicates ODE)
  • Is the system... (boolean responses only)
    • a DAE? (must be 1 if differentiation index is nonzero)
    • affine parametric?
    • block structured?
    • bilinear?
    • control affine?
    • dissipative?
    • nonlinear?
    • passive?
    • Port-Hamiltonian?
    • square?
    • stable?
    • state-space symmetric?
    • symmetric?
    • quadratic bilinear?

Additional metadata will be automatically generated internally for the purposes of searchability and categorization.

3 Data Files

All the numerical data for the collection is regarded as a list of matrices, a vector being a m x 1 matrix. Consequently, we have implemented a strict naming scheme for matrices corresponding to different models. See Models.

An author can suggest another naming standard in the case when the templates outlined in Models are insufficient. Otherwise exceptions will not be permitted.

3.1 File standard

A single benchmark instance should be saved in the .mat (https://de.mathworks.com/help/matlab/import_export/mat-file-versions.html) file format. To accommodate multiple languages, features, and the benchmark comparison tool (currently under development), we recommend v7.2 (https://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.io.loadmat.html). For example, the file associated to CD Player contains three matrices A, B, C.

Other file formats are accepted, as long as the naming scheme outlined in Models is adhered to. The editors reserve the right to adapt any data to fit our standards, and we may additionally add metadata to .mat file.

4 References

Editors:

Retrieved from "https://modelreduction.org/morwiki/index.php?title=Submission_rules&oldid=3913"