The current workflow for CAESAR's buried piping goes as follows:

1. Manually note node numbers in the preprocessor where buried pipe starts, stops, and have changes in elevations, making sure to break the pipe at grade. Preferably leaving yourself plenty of nodes in between so nodes can remain linearly defined.
2. Exit the preprocessor, enter the buried model spreadsheet.
3. Specify soils models.
4. Define where the various models start/stop from step 1.
5. Hit "run" to convert your "unburied model" into a "buried" model.
6. Stress problems? Reroute your original file, go back to step 1.

If we have to maintain a separate processor to "bury" our pipe, independent of our preprocessor, then here are some quality of life suggestions:

1. Define in the preprocessor where soils models starts and ends. Even better if you can define soils models and assign them, as well as mesh refinement. Even better if there's a color code option, like for temperature, pressure, etc.
2. CAESAR duplicates the pipe routing information for sections that are to be buried, probably in an external file.
3. Buried model input editor reads the information from the preprocessor and fills out the buried model spreadsheet for the user.
4. Create a new buried model, per usual, which can probably overwrite the original model.
5. Upon initial opening of a freshly buried model, CAESAR compares the new buried file against the information in step 2, and notes the differences for the "buried" sections.
6. If the analysis fails, the user can go back to the preprocessor, and instruct it to restore the "unburied" state of the pipe with the information stored in step 2, making a backcheck against the information in step 5, in case the user inadvertently changed an underground dimension or something to that effect.

Benefits:
1. One linear path to the end result, rather than dealing with branched CAESAR files.
2. Soils models inputs remain persistent and checkable.
3. Visual confirmation on burial parameters prior to burial.

Once the buried model is built YOU CANNOT SEE THE INPUT VALUES THAT WERE USED TO GENERATE THE BURIED MODEL. This should be stored in the misc output or remain intact somewhere. Typically the base file is not retained and engineers do not list the parameters used on the CII title page or elsewhere. As Michael is getting at is that there is a QA issue in addition to design iteration maintenance issues.

Additional suggestions:

1. Separate "soil model" from "depth." In my mind, "soil model" should define the soil material only. "Depth" in our current configuration should be defined on the sheet.

2. Import/Export soil properties.

Benefits:
The fewer inputs and cross references the user has to make, the fewer mistakes that can be made.

These suggestions are noted. When we redesign this area of the software these ideas will be addressed in some form.

Michael, you mean something like this? https://www.youtube.com/watch?v=PDHomizl2f0&t=795s

what about inserting a button to view the colored piping based on the type of soil used and what is/is not underground?. as already we do to see the temperature and the pressures of the complete pipe system.

many times you find a mistake in table only after simulation run, when you find supports changed also in above ground pipes. and you have to reopen the table, find the mistake, correct it and re-launch the run.

Somehow I missed this response. Yes, this functionality appears equivalent to what I described.