Name

b2000++ — Run a B2000++ analysis.

Synopsis

b2000++ [OPTIONS] MDL_FILENAME

b2000++ [OPTIONS] DBNAME

Description

The b2000++ program solves or analyzes a problem described by the MDL file MDL_FILENAME or by the database DBNAME. The b2000++ program is launched from a shell.

Arguments

MDL_FILENAME

B2000++ MDL file (required). MDL_FILENAME must end with the suffix .mdl.

DBNAME

Alternatively, the B2000++ database can be specified, the database name must end with the suffix .b2m, and the database must exist.

If MDL_FILENAME is specified, the b2000++ program invokes the input processor b2ip++ to create a database with the same name but with the suffix .b2m instead of .mdl. Then, the b2000++ program proceeds as if launched with that database: It reads the geometry, the properties, analysis case definitions etc. from that database, calculates the solution and gradient fields and stores them on the database.

In the following, the example MDL file demo.mdl is used to illustrate the different command-line options.

The shell command

$ b2000++ demo.mdl

is equivalent to

$ b2ip++ demo.mdl
$ b2000++ demo.b2m

It creates the B2000++ database demo.b2m which contains the nodes, elements, materials, properties, etc., as well as the solution and gradient fields that were calculated by the b2000++ program.

Options for MDL variables, analysis control, and event logging

-adir [case].key=value

Add or override an analysis directive. See the section called “Specifying analysis directives on the Command-line” for more information and examples.

-define VARIABLE=VALUE

Set the MDL variable to the specified value. This option can be specified multiple times. In conjunction with the conditional MDL assignment operator ?=, default values can be set in the MDL file that can be overridden with the -define option on the command-line. See the section called “Defining MDL Variables on the Command-line” for more information and examples.

-l ...

Log events. See the section called “Event Logging” for more information and examples.

Options for resource control

-max-cpu time

Set the maximum allowed CPU time (in seconds) to time. When this time limit has been reached, the b2000++ program aborts. By default, no limit on the CPU time is imposed.

-max-mem size

Set the maximum allowed size of allocated virtual memory (in MBytes). When the allocated memory has reached or exceeded this limit, the b2000++ program aborts. By default, no limit on the virtual memory size is imposed.

Options for online help

-h

Print a one-line help message containing the synopsis of the b2000++ command and exit.

-help

Print a summary of the b2000++ command-line arguments and options and exit.

-version

Print the version of B2000++.

Options for debugging purposes

-backtrace

When this option is enabled and an unexpected termination occurs (C++-exception not handled or signal to terminate the process) , the stack backtrace will be written to the console (standard error). This option must be the first in the argument list.

-fexp

Enable traps of the floating-point exceptions FE_DIVBYZERO, FE_INVALID, and FE_OVERFLOW. These traps will trigger a C++ exception.

-gdb

Start b2000++ in the gdb debugger and stop at the start of the main function. This option must be the first in the argument list.

-list-loggers

At the end of the program's execution, print the list of all encountered log names to the console. Note that this list is problem-dependent, i.e. it depends on what elements, materials, solvers, constraints, etc. are invoked.

-list-types

At startup, print the list of all registered C++ objects (solvers, elements, boundary conditions, etc.) and exit.

-nocatch

Do not catch any C++ exception nor any signal in the main function.

-valgrind[,valgrind_option,...]

Start b2000++ in valgrind. This option must be the first in the argument list. If valgrind_option is present, it is split into multiple valgrind options at the commas. For example, '-valgrind,--db-attach=yes' passes '--db-attach=yes' to valgrind.

Event Logging

By default, the b2000++ program stores only a small number of event messages, these are written to the file DBNAME/log.txt. For example, after executing

$ b2000++ demo.mdl

the log file contains the following:

$ cat demo.b2m/log.txt
INFO:all:16:54:12.886: Start
INFO:solver.linearised_prebuckling:16:54:12.887: Start the linearised prebuckling solver for the case 1.
INFO:domain:16:54:12.887: Total number of DOfs: 105.
INFO:solver.linearised_prebuckling:16:54:12.887: Assemble the linear problem.
INFO:solver.linearised_prebuckling:16:54:12.888: Element matrix assembly
INFO:solver.linearised_prebuckling:16:54:12.888: Resolve the linear problem
INFO:solver.linearised_prebuckling:16:54:12.889: Compute gradients and reaction forces
INFO:solver.linearised_prebuckling:16:54:12.890: Assemble the stability matrix.
INFO:solver.linearised_prebuckling:16:54:12.891: Eigenvalue problem resolution
INFO:solver.linearised_prebuckling:16:54:12.894: End of linearised prebuckling solver
INFO:all:16:54:12.894: End of execution

Event logging is controlled with the command-line option -l. The most common use is to print the progress of an analysis onto the terminal, which is the same as what is written to the log file by default.

$ b2000++ -l info demo.mdl
INFO:all:16:54:12.886: Start
INFO:solver.linearised_prebuckling:16:54:12.887: Start the linearised prebuckling solver for the case 1.
INFO:domain:16:54:12.887: Total number of DOfs: 105.
INFO:solver.linearised_prebuckling:16:54:12.887: Assemble the linear problem.
INFO:solver.linearised_prebuckling:16:54:12.888: Element matrix assembly
INFO:solver.linearised_prebuckling:16:54:12.888: Resolve the linear problem
INFO:solver.linearised_prebuckling:16:54:12.889: Compute gradients and reaction forces
INFO:solver.linearised_prebuckling:16:54:12.890: Assemble the stability matrix.
INFO:solver.linearised_prebuckling:16:54:12.891: Eigenvalue problem resolution
INFO:solver.linearised_prebuckling:16:54:12.894: End of linearised prebuckling solver
INFO:all:16:54:12.894: End of execution

The syntax of the -l option is as follows:

-l 'level [of names [in destinations]]'

The quote characters can be omitted if only level is specified.

The meaning of level, names and destinations is described in the following:

  • To each log message a level of importance is associated:

    critical|error|warning|info|data|debug

    Those levels are, in increasing order, debug, data, info, warning, error and finally critical. If the level is set to info, all messages of importance info plus all messages of higher importance (warning, error, and critical) are logged. All other messages are suppressed.

  • In addition to the level of importance, to each message, a comma-separated list of names is associated. The most important logger names are:

    all

    All logging events (default).

    elements

    Logging events created by element objects.

    linear_algebra

    Logging events created by sparse-matrix (linear algebra) solvers. In conjunction with the debug level, this will print an extensive report including the time spent for the matrix factorization and an error analysis on the linearized system of equations.

    solver

    Logging events created by (linear and nonlinear) Finite-Element solvers.

  • The comma-separated list destinations indicates where the log message is output. The most common is cout (default), meaning that colour-highlighted log messages will be printed to the terminal.

    err|cerr|out|cout|file|db|raise

    The available destinations are:

    cerr

    The standard error stream[10] with colour highlighting.

    err

    The standard error stream without colour highlighting.

    cout

    The standard output stream with colour highlighting (default).

    out

    The standard output stream without colour highlighting.

    file

    The text file DBNAME/log.txt.

    db

    The MemCom database DBNAME/log.mc. Can only be used in conjunction with data. Useful for debugging purposes.

    raise

    When a log message is generated, raise a C++-Exception. Useful for debugging purposes.

Examples:

$ b2000++ -l 'debug of linear_algebra' demo.mdl

Prints all messages from the sparse matrix solver and from the analysis solver to the terminal. The content of the log messages depends on the type of sparse matrix solver (see Sparse Linear Solvers) but typically includes the condition number of the global stiffness matrix, the number of floating-point operations and the time that was needed for factorization.

$ b2000++ -l 'data of elements' demo.mdl

Prints all element-specific messages of level data or higher of all names starting with elements to the terminal.

Multiple logging directives can be specified:

$ b2000++ -l 'data of elements,solver in db' demo.mdl

which writes element-specific and solver-specific data log messages to the logging database. The logging database demo.b2m/log.mc contains the per-element stiffness matrices, the global stiffness matrix, and other data.

Defining MDL Variables on the Command-line

Parametric MDL files can be steered from the command-line by means of the -define command-line option. It sets the variable to the specified value. This can be used to set variables that are not set in the MDL file, or that are set with the operator ?=. The values that can be assigned to MDL variables with the -define command-line option are restricted to constants of the following types:

  • A string.

  • The bool values true and false.

  • An integer number.

  • A floating-point number.

The following specifies a different element type and a finer mesh for the demo.mdl example:

$ b2000++ -define eltype="T3.S.MITC" -define mr=4 demo.mdl

Note that the quote characters " around the string value T3.S.MITC could be omitted since it contains neither spaces nor any other special characters such as * or ? that would be expanded by the shell.

Specifying analysis directives on the Command-line

One or several analysis directives can be specified on the command line; they override what was specified in the MDL file.

In the following example, the free-vibration modes are calculated instead of the buckling modes:

$ b2000++ -adir case1.analysis=free_vibration demo.mdl

The syntax is as follows: The -adir option is followed by a string of the form [case.]key=value where case indicates the analysis case, i.e. "case1" indicates the analysis case 1. If the case is omitted, the settings in the adir section will be overridden instead. key is a string and value is one of the following:

  • A string. For example -adir case1.analysis=linear will insert for the analysis case 1 the MDL command analysis linear.

  • An integer number.

  • A floating-point number.

  • An array of integer numbers, enclosed by quotes (").

  • An array of floating-point numbers.

Error Messages

The b2000++ program prints error messages in the following format: Error messages start by ERROR: followed by an optional category, the time stamp, and the message:

ERROR:category:hh:mm:ss.ms: Error message

The following table list a number of common error messages related to inconsistencies in the MDL file which are not detected by the input processor, but which are detected by the b2000++ program instead:

Error message Comments and possible solutions

Incompatible essential boundary condition for set EBC.*.0.0.x entry ???, expected value is y but given value is z

Multiple essential boundary conditions have been defined at specific DOF's of specific nodes. Check the definition of essential boundary conditions (MDL ebc command) of the ebc set x and their possible interference with MDL commands join and linc.

DBError: The number of dofs of node is less than the dof number specified in the database (has node a type?). Dataset: ... A boundary condition has been applied to a node which is not connected, i.e. it has not been assigned to an element.

Example MDL File

The following parametric MDL file demo.mdl represents a buckling analysis of a supported plate under compression:

# Parameters
(l?=3)                # length
(w?=1)                # width
(t?=0.01)             # thickness
(eltype?="Q9.S.MITC") # element type
(mr?=0)               # mesh refinement factor 0, 1, 2, 3...

# element size
(h=1./2**mr)

epatch 1
  geometry  plate
  p1        0    0  0
  p2        (l)  0  0
  p3        (l) (w) 0
  p4        0   (w) 0
  thickness (t)
  mid       1
  eltype    (eltype)
  ne1       (max(1,int(l/h)))
  ne2       (max(1,int(w/h)))
end

material 1 type isotropic
  e 73.1e9
  nu 0.3
  density 2.78e3
  failure von_mises
    r 138e6
    filter max_of_element
  end
end

ebc 1
  dof [   UY UZ]  value 0.  epatch 1 e1
  dof [   UY UZ]  value 0.  epatch 1 e2
  dof UX value -1. epatch 1 e2
  dof [   UY UZ]  value 0.  epatch 1 e3
  dof [UX UY UZ]  value 0.  epatch 1 e4
end

case 1
  analysis      linearised_prebuckling
  nmodes        10
  ebc           1
  gradients     1
  rcfo_restrict epatch 1 e2
end

adir
  case 1
end


[10] An explanation of the standard error and standard output streams can be found here. In the general case, standard error means unbuffered output to the terminal, while standard output means buffered (faster, but not immediate) output to the terminal.