Management of databases and load cases

IV.4.1.1 Management of databases and load cases

Module “DbAndLoadCases” is devoted to the management of FEM databases and load cases. Three classes are defined in the module:

class “DbAndLoadCases.DB” stores the data used for the one FEM dataBase definition. In the project, FEM dataBases can correspond to Nastran or Samcef models. The different FEM dataBases are stored in “DbAndLoadCases.databases’ member data. A database is created and stored simply with instructions like:
    db=DbAndLoadCases::DB.new(dbName,"NASTRAN",bdfFileName,
        sesFileNames,claDbs,gmshFileName)
    DbAndLoadCases.databases[dbName]=db

(See source code and examples for a description of the arguments of “DbAndLoadCases::DB.new” method.)
Class “DbAndLoadCases.ElemLc” is devoted to the storage of elementary load cases. An elementary load case corresponds to a set of results that can be directly accessed from a Nastran or Samcef result file by identification of its load case and sub-case names. An elementary load case is created and stored in the module as follows:
    lc=DbAndLoadCases::ElemLC.new(name,dbName,resFileType,resFileName,
        resFileLcName,resFileScName)
    DbAndLoadCases.elemLoadCases[name]=lc
Class “DbAndLoadCases.CombiLC” is used for the management of combined load cases. More precisely, this class allows the creation of Results obtained by linear combinations of elementary load cases Results, already loaded into a FEM dataBase. A combined load case is defined with instructions like:
lc=DbAndLoadCases::CombiLC.new(lcName,factors,elemLcNames)
DbAndLoadCases::combinedLoadCases[lcName]=lc

Note that a limitation of post-processing project, is that the elementary load cases used for the definition of a combined load case must be loaded in a single FEM dataBase.

All the static load cases that have been defined in “DbAndLoadCases” module are not necessarily post-processed. The list of static load cases to be post-processed is specified via following instructions:

DbAndLoadCases.addOneSelection(lcName,params)

The definition of databases, elementary and combined load cases, and of the selection of static load cases are a preliminary step in the post-processing project. This means that corresponding entities must be defined before the loop on static load cases which looks as follows:

    DbAndLoadCases.loopOnStaticCases() do |lcName|
        puts lcName
        postList.each do |p|
            begin
                p.initCalcSteps()
                p.calculate("Static")
            rescue Exception => x then
                printf("Failed Post object %s with ID %s' n",p.to_s,p.postID())
                PrjExcept.debug(x)
            end
        end
        DbAndLoadCases.saveMosResults(postList)
        DbAndLoadCases.saveSrResults(postList)
    end

For dynamic load cases (post-processing of Nastran SOL 111 analysis), no elementary or combined load cases are defined. Instead, the loop on the different sub-cases is done via instructions that look as follows:

    db=DbAndLoadCases::DB.new(dbName,"NASTRAN",bdfFileName,
        sesFileNames,claDbs,gmshFileName)
    DbAndLoadCases.databases[dbName]=db

    DbAndLoadCases.prepareDataBase(dbName)

    DbAndLoadCases.loopOnDynamSubCases(resFileType,resFileName,
            lcName,fMin,fMax,scNbrMax) do |lcNameA,lcNameB|
        puts lcNameB
        postList.each do |p|
            begin
                p.initCalcSteps()
                p.calculate("Dynamic Complex")
            rescue Exception => x then
                printf("Failed Post object %s with ID %s' n",p.to_s,p.postID())
                PrjExcept.debug(x)
            end
        end
        DbAndLoadCases.saveMosResults(postList)
        DbAndLoadCases.saveSrResults(postList)
    end

(The loop on sub-cases is obtained via an iterator directly defined in “DbAndLoadCases” without defining “ElemLc” or “CombiLc” objects.) Note that, another iterator is associated to dynamic (complex) results:

    DbAndLoadCases.iterateOnTheta(currentLcName,bakResults) do |srLcName,mosLcName,results|
        # One performs the calculations with the Real results :
        @step_1_results=results
        calc_2(srLcName,mosLcName)
    end

This iterator produces real Results from the complex Results , corresponding to different phases. (In out post-processing 12 phases are considered for each output frequency.) This iterator is called by the “calculate” method defined in “GenPost” class described in section IV.4.1.2.

“DbAndLoadCases” module also defines the methods that can be used to store results in an SQL database:

Method “DbAndLoadCases.getOutputSqlDb” is used to open (and create if necessary) the SQL database into which results are stored. Method is simply called as follows:
DbAndLoadCases.getOutputSqlDb("OUTPUTS/results.db3")

(The link to SQL database is stored in the “DbAndLoadCases” module.) Note that when the dataBase is created several SQL tables and views are also created in the database.
“DbAndLoadCases.saveMosResults” method is used to store post-processing results in the “excel-like” tables of SQL database. The argument of the function is an Array containing a list of post-processing objects. (See section IV.4.1.2.)
“ DbAndLoadCases.saveSrResults” method is used to store Strength Ratios in the “StrengthRatios” table of SQLite database. (See section IV.4.1.2 for the definition of Strength Ratios concept.)
The iterators on static and dynamic load cases also save load case or subcase information in “loadCasesInfos” table.

Note that “DbAndLoadCases” module is unaware of SQLite. All interactions with SQL database are done via “SqlWrap” module discussed in section IV.4.1.3. This has been done to ease the swap from SQLite to another SQL database system.

[next] [front] [up]