Starting with version 970, a binary format for the so-called ASCII output files (matsum, rcforc, etc.) is available. MPP-DYNA runs do not write ASCII output files directly but instead write the data to binary database(s). There are two formats for this data: dbout (see Appendix L, p. L.3 in the v. 970 User's Manual) and binout. The default for MPP is to write the binout style of database. The second input parameter of *database_matsum, *database_rcforc, etc., called "BINARY", controls what type of output will be written. 1 = old format, i.e., ASCII files (SMP) or dbout files (MPP) 2 = new binout format (this is the default for MPP) 3 = both formats written *CONTROL_MPP_IO_BINOUTONLY will cause the aforementioned parameter "BINARY" to be ignored in an MPP run and binout* files, rather than dbout* files will be written. LS-PrePost can read, convert, and plot the binout data directly. In LS-PrePost, select Post>Binout>Load>binout0000>Open Click to highlight the loaded file. From there, you can go on to plot the data without ever having to actually create ASCII files or you can go ahead and write ASCII files, e.g., matsum, rcforc, etc. as follows ... Click Save. Highlight the ASCII files of interest. Check the box that says "As ASCII(es)". Click Apply. The ASCII files will be created in your current working directory. Now you can go to Post>ASCII in LS-PrePost to plot the ASCII versions of the data. Alternate way to extract ASCII files from binout files: There are two programs that are available as part of our lsda package (see the "lsda" directory under the user account of our ftp site). One is "l2a" which will extract the various ascii files from a binout file. The other is "ioq" which is a small utility that lets you read/explore the binout file directly. An "l2a" executable is generally included in the same tar file that contains the MPP executable for your platform but you can also use that l2a to operate on binout files produced by any LS-DYNA executable: MPP or SMP, single or double precision, any platform.[1] Or, one can pull the lsda package itself from the user ftp account, under lsda/lsda-1.2.1.tar.gz, then build their own l2a on their system. To do this: extract the tar file, then "cd test ; make linuxnof" That should build some lsda tools, including a fairly recent l2a. To extract the ASCII files from a binout file, execute l2a and include the name of the binout file on the execution line, e.g., "./l2a binout.0000". This may be done for individual ASCII files also in a running simulation, e.g.: l2a binout* matsum nodout -> only matsum and nodout are extracted (please use actual l2a-tool out of the mpp package for 971-R3.2.1 or newer; you may always use the newest "l2a" also for binout-files of any previous version). ***l2a update pertaining to conversion of binouts from multiple jobs (typical when *CASE is used in LS-DYNA)*** To "handle multiple jobs at once", type, for example, l2a -j case*.bino* You'll need l2a from Dev branch r71669 or later. Binout files are platform-independent, i.e., you can process binout data written by one platform on that same platform or on any other platform. When a binout database is written by an MPP LS-DYNA executable, there will be more than one file with the "binout" rootname. In the d3hsp file, you'll see something like the following which tells you what data is contained in each binout file: > The following binary output files are being created, > and contain data equivalent to the indicated ascii output files > binout0000: (on processor 0) > nodout > glstat > matsum > rcforc > abstat > rbdout > sleout > jntforc (type 0) > binout0001: (on processor 1) > jntforc > binout0003: (on processor 3) > deforc If you load the first binout (default name "binout0000") or any of the binout files in LS-PrePost, the software knows to load the whole family of binout files that share the same rootname (default rootname is "binout"). Alternative control of output format for MPP (from Jason): if you put the following line in your pfile pfile: gen { dboutonly } to execute: mpirun -np ## mpp970 i=... p=pfile The program will output dbout.* as before and you can use dumpbdb to extract all the ASCII files. Notes: 1. Before l2a there was "dumpbdb" which read the dbout.* files and produced the ascii files from them. The format of the dbout.* files depended on the particular executable (single vs. double precision, and bigendian (eg IBM) vs littleendian (eg Intel)). Using the wrong dumpbdb program on a given dbout.* file could result in garbage. So LSTC got in the habit of building executable specific dumpbdb executables and distributing them with the executable, so everyone would always have the correct program. We continue to do this with l2a, but really that isn't necessary. The LSDA library used for writing the binout.* files corrects for all these differences internally. Different executables will produce different binout files (single/double, big/little endian), but it doesn't matter: any l2a can read any binout file. So really, all they NEED is SOME version of l2a that runs on the machine where they are doing the post-processing. They do NOT need a different l2a for each version of DYNA. Now, sometimes things are changed, added to, or fixed in the binout files, so newer versions of l2a should always be preferred over older versions. New l2a executables should be able to handle all old binout files, but of course not the other way around. So probably we should just have a single "l2a" distributed for each platform. Our current approach has the advantage that the user doesn't have to look for l2a separately -- if they download an executable they WILL get an l2a. Probably he should name them differently, so they are more obviously tied to the machine, not the specific executable. Brian 6/17/10 ________________________________________ Q: If my binout data from a restart was written to a different directory than where the preceding binout data resides, can I postprocess all the binout data together? A: Yes. Case 1: if you are trying to pass these files to the l2a program, you don't need to do anything except move all the files to one directory and specify them all on the command line, like this: l2a *binout* It will read them all and make sense of them. (Note: if you are doing your own LSDA programming using the LSDA library, this is very easily achieved by using the "lsda_open_many" function, which allows a number of files to be opened and read as if they were a single file...) Case 2: if you are trying to use lsprepost, or some utility of your own that you wrote using the lsda library, here is another simple work around. Much like the d3plot/d3plot01/d3plot02/etc files, where each is a known extension of the others, LSDA supports an extension mechanism (to handle files that would otherwise be very large). By default, if a binout file gets to be above about 1GB, a 3 digit number is appended, preceded by a % sign: binout0000 binout0000%001 binout0000%002, etc. The 1GB limit is arbitrary and imposed when MPP-DYNA writes the files -- the reading routines don't care about the sizes of the individual files. So, if you rename your _binout0000 (from the restart) to binout0000%001, then opening just binout0000 should get you all the data from both files. _____________________________________________________________________ Regarding how specific ASCII data is distributed to various binout files: Each type of output data is output by the lowest numbered processor participating in that output type. For example, if "nodout" is desired, only processors having some data to go out to the nodout file will participate in its output, and the lowest numbered one (say for example, 7) will then write that output to a binout file with its number (in this case, binout0007). So the number of such depends on the data requested, the number of processors used to run the problem, and the decomposition (which data ends up where). There is a summary output in the d3hsp and to the screen when the problem starts, like this: The following binary output files are being created, and contain data equivalent to the indicated ascii output files binout0000: (on processor 0) rwforc glstat matsum rcforc sleout binout0009: (on processor 9) nodout binout0012: (on processor 12) deforc binout0047: (on processor 47) jntforc (normal) Some of the ascii files are in fact output in several pieces. Like elout, which has separate output for solids, shells, beams, etc, and so can be split up over several binout files. jntforc (as in the output example above) is another (normal joints, and flexture-torsion or "general" joints are output separately). Furthermore, if a LOT of data is output, any binoutXXXX file will then generate a "family" of files named binoutXXXX%001, binoutXXXX%002 and so on (each about 1GB in size). _________________________________________________________________ RE: binout files that end with an underscore (_): An underscore is appended to the binout filename, e.g., binout0000_, when LS-DYNA can't find the existing binout file to reopen during a restart. A bug, whereby binout0000_ was created even in the presence of binout0000, was fixed in r73513. If you're using l2a to process the binout data: There is some header data in binout0000 that is NOT in binout0000_, so l2a can become confused. The solution is pretty simple: l2a can be fed multiple files at a time, so they can just "l2a binout0000 binout0000_" and it should be fine: all the data is still there, and l2a will find it. If you're using LS-PrePost to process the binout data: You can rename the binout files that have "_" at the end by replacing "_" with %001, %002, etc. After renaming, your series of files should be, e.g., binout0000, binout0000%001, binout0000%002, etc. The good news is that starting with r85895, LS-DYNA will no longer create binout files that end with an underscore (-). Rather, the file naming scheme where binout files end in %XXX is followed automatically without user intervention. ______________________________________________________________________ RE: Number of digits in ASCII output It is completely out of the question to change the format of the existing ASCII files, as that would break so many things If more digits are needed in NODOUT and ELOUT, then the user should output the BINOUT version of those files from double precision LS-DYNA, and post-process that binout data with a custom-built l2a utility code. Use the LSDA package to create a custom version of l2a where the NODOUT and ELOUT write statements are modified to output as many significant figures as desired. Then it's up to the user to decide how to read this non-standard format of NDOOUT/ELOUT. Download LSDA (Livermore Software Data Archival) here: http://ftp.lstc.com/user/lsda/ (username=user and password=computer) The LSDA database format is well documented, and the binout format is documented also. The LSDA tar package on the FTP site includes all the source code and documentation necessary for them to read the binout file directly and get all the accuracy that is there to be had. It includes C and Python libraries and sample code, as well as the full source code to the l2a program itself, which they are free to modify in any way they want. If they don't have the requisite coding skills in house, I'm sure they could find an enterprising third party who would be happy to write them some custom extraction routines for a nominal fee, or perhaps ANSYS could provide that service. ts Ticket#2017062910000144