Troubleshooting Errors


Question

What are the common troubleshooting procedures I should follow before submitting a help ticket?

Answer

When a SACS analysis fails, it can be difficult to identify why the analysis failed and what steps might be taken to fix the problem. This document provides troubleshooting steps that you can take to help identify and potentially resolve analysis errors.

Most input errors will occur in the SACS model. There are three (3) main places where input files may be checked for validity. SACS input is documented in the manual, the input line documentation, and in the Datagen.

Typically, the Input line documentation will include the most detailed information about the input. However, additional context is sometimes provided in the body of the manual if the line in question is dependent upon other input lines.

The Precede command Misc > Check Model will validate the model for some common errors. Note that some reported errors are not necessarily an indication that there will be issues with the analysis. Check Model can give some clues as to why a model may be experiencing errors.

 

To troubleshoot the errors, the following procedures can provide overall guidance:

  1. Missing Input Lines
    Check the Samples and Input Documentation for similar examples. Be sure to include those lines.
  2. Input Line Order
    Again, check the Samples and Input documentation for similar examples. You can also check the expected input by selecting the Insert Input Line command in Datagen.

  3. Incompatible Options
    Some options are dependent upon other options to work. Again, check the Samples and Input documentation for similar examples.

  4. Float Decimal Input
    Floating point values require a decimal in the input. In some cases, the value is interpreted with an implicit decimal point, changing the order of magnitude of the input value. Always add decimal points to floating-point input.

  5. Blanks don't necessarily mean zero
    Blank fields typically mean 'Default'. Refer to the input line documentation in the manual for default values.

  6. Corrupted Analysis Runfiles
    Sometimes, runfiles may become corrupted or incompatible with newer versions. Try recreating the runfile from scratch.

  7. Unit Consistency
    Try keeping units consistent across input files. These conversions sometimes cause issues.

  8. Analysis error
    If an analysis exits with an error, we can identify where the analysis stopped by referring to the Start and Finish messages. The program that exited with an error will just have a Start message. For instance, if there was an error in the Post Processor, we would just see the Start Post Processor message. This error may be related to input errors related to previous programs, but this will give us our first place to start digging into the error.



    You will often be able to identify the source of the problem by reviewing the listing file. Error and Warning messages will be printed to the Error Log pane in SACS Executive. Double-clicking the error message will open the relevant listing file. SACS will sometimes print additional relevant output before or after the Error message that can provide additional context. The location of the Error can also provide some clues as to what happened in the analysis. For instance, if the analysis stopped after the member properties report, but before or during the plate properties report, that is a good indication that something went wrong with reading the plate properties, so more scrutiny should be applied to the plate definition input.



In the end, engineering expertise is required to truly understand the issues. Be sure to ask yourself what input would be required for this analysis by hand. Question the input if that does not conform to the workflows suggested in design codes, etc. Sometimes errors should be apparent once you understand the purposes of each program and how they fit into the SACS analysis workflow.