This file is probably the best file to save in terms of compactness. Also, this file is a record of the commands you used to create your model, so you will probably recognize the steps that you used, and why you did operations in a particular order. Since the file is saved in text file format (normally ASCII), you can transfer it from one machine to another through such methods as E-mail, etc. In addition, since you can modify these files with any text editor, you can change your model by changing this file, and you can add /COM commands (comment lines) to describe your input. This will help you understand the input at a later date. Parametric models (and therefore models used in optimization analyses) can be archived using the log file. Finally, this is the best file to give to other people (perhaps your Support Representative) who are helping you with questions or problems.

You will have to rerun the input in this file in order to get a database. Because such things as entity numbering, meshes, etc. can change between different hardware systems or between releases of Mechanical APDL, you'll probably need to rerun the input at the same release of the program that you originally used to create the model. Also, if you created your model interactively, you may have difficulty running the input on this file in batch mode to recreate the model. If there are any errors in the input, they can terminate a batch run, which means that your model will not be built completely. If you encounter this problem, run your input interactively with the /INPUT command.

The database file can be resumed (RESUME) within the Mechanical APDL version that the file was created in. As long as you are resuming the file into the same Mechanical APDL version that it was created in, you do not need to manipulate or modify the file in any way.

Large models can produce large database files, which can soon cause you to run out of disk space. Also, because this file is saved in binary format (IEEE), transfer from one machine to another is sometimes more difficult than with a text file.

Relatively compact text file(s) (with the .cdb extension) are produced by the CDWRITE operation. Since CDWRITE saves the current model in terms of geometric and finite element entities (rather than the commands used to create the model), nearly all hardware platforms and or program release dependencies are eliminated. CDWRITE files can typically be used to recreate a model on any hardware platform and in any upward compatible release of the program. Also, because these files can be modified with a text editor, you can put descriptive comments in these files to help you identify and understand them at a later date. Imported files used to create the model need not be saved.

Files produced by CDWRITE are essentially a text file format dump of the database. While Mechanical APDL commands (and possibly IGES information) are contained in the files, they may not be the same commands that you used to create your model, and they will not be in the same order as the commands that you used. For this reason, it is difficult (and not recommended) to modify these files when you are trying to change a model. Parametric model information is not saved, so changing the model by modifying parameter values is not possible. For this reason, it is also not possible to save a model to be used for an optimization analysis using CDWRITE. Also, to recreate your model, you must read these files in with the CDREAD command, which can take a moderate amount of time for large models.

Note that, if a set of data exists prior to the CDREAD operation, that data set is offset upward to allow the new data to fit without overlap. The NOOFFSET command allows this offset to be ignored on a set by set basis, causing the existing data set to be overwritten with the new data set