I/O Error Resolution — FEA/CFD Input/Output Errors

In Abaqus 6.14, NLGEOM is a step-level parameter: *STEP, NLGEOM=YES. More likely though, you have a stray character — an invisible non-ASCII space or smart quote — pasted from a PDF or Word document. These look identical to regular characters but cause parser failures. Open the .inp in a plain-text editor that shows invisible characters (like VS Code or Notepad++), or run file mymodel.inp to check encoding.

In the .dat file, search for ***ERROR — Abaqus uses three asterisks for fatal errors. Above or below the error message it prints the exact input line that caused the problem. For deprecated keywords, the message often includes "use X instead of Y" — Abaqus is helpful about this. The .msg file captures runtime messages the .dat doesn't always show. Use the datacheck option to parse keywords without running the solver, which gives fast I/O feedback.

Almost certainly a case sensitivity problem. Abaqus set names are case-sensitive in the .inp file. If the set is defined as Set-1 (capital S) but referenced as set-1 (lowercase) or SET-1 (all caps), Abaqus won't find it — even though it's right there. Search the .inp file for all occurrences of the set name and confirm perfect case consistency throughout.

Exactly right. Sets defined under a *Part block are part-level and must be referenced at the Assembly level with their instance prefix — for example PART-1-1.Set-1 rather than just Set-1. The dot notation specifies the instance. If you reference the bare set name at Assembly level, Abaqus looks for an assembly-level set with that name, finds nothing, and fails. Alternatively, export your model as an orphan mesh (no Part/Assembly structure) to avoid this scoping complexity when hand-editing .inp files.

A lock file artifact from a previously crashed job. ANSYS creates a .lock file in the working directory when a job starts and removes it when the job completes normally. If the job crashes or you force-quit, the lock file is never cleaned up. Next time you try to run, ANSYS sees the lock file and refuses, thinking the previous job is still active. Delete the jobname.lock file from the working directory manually — it's just a marker file and is safe to remove.

For the existing run, you can't shrink the RST file retroactively — you'd need to re-run with selective output. But you can open it in chunks using ANSYS Mechanical's "Result file chunking" or read specific time points with APDL commands like SET,,,,,time_value rather than loading all states at once. For future runs, use OUTRES to request only the quantities and time intervals you actually need — this can reduce file size by 10 to 100 times.

Classic Linux case sensitivity trap. OpenFOAM on Linux is case-sensitive, and so is the filesystem. If you created the directory as Constant (capital C) or the file is named Boundary (capital B), OpenFOAM will not find it even though it's right there. Check with ls -la constant/polyMesh/ and compare every character. Also verify you're running the solver from the correct case root directory — OpenFOAM resolves paths relative to where you launch the command.

"Wrong token type" means the parser expected a keyword but found something unexpected — usually a missing semicolon on the previous line, a stray character, or a mismatched brace. Line 47 is where the parser gave up, but the actual mistake is almost always one or two lines earlier. Count your opening and closing braces carefully, and confirm every value line ends with a semicolon. OpenFOAM dictionary syntax is strict: every value ends with ;, every block opens with { and closes with }.

Yes — use DebugSwitches in system/controlDict. Setting blockMesh 1 enables verbose parsing output. For file-not-found errors, try running with simpleFoam -verbose. The foamDictionary command-line tool lets you parse and query any OpenFOAM dictionary file interactively to spot syntax issues before running.

2 GB per state shouldn't be a problem for modern LS-PrePost, but check whether all split files exist. LS-DYNA splits large results into d3plot, d3plot01, d3plot02, and so on — you need all of them to reconstruct the complete time history. Run ls -la d3plot* to see the full set. If only a single d3plot file exists for a large model, the write may have been cut off mid-file (disk full, killed process). Check disk space and the d3hsp text log for write errors.

DATABASE_HISTORY defines what to track (node sets, elements), but you also need the corresponding *DATABASE_BINARY_D3THDT card to actually enable the output file. These are separate — like having a sensor installed but no recorder connected. Also check: the DT parameter on DATABASE_BINARY cards must be non-zero and smaller than the simulation end time. If DT is set to 0.0, LS-DYNA silently skips the output with no error message.

Abaqus jobs don't consume 1 token — they use multiple tokens depending on the CPU core count and analysis type. A single Abaqus Standard job on 8 CPUs might consume 5 tokens; Explicit consumes even more. Run abaqus licensing lmstat to see the exact token consumption per user. Also, "ghost" checkouts from crashed jobs can hold tokens that appear available in the GUI but aren't released. Restarting the license daemon with lmreread or a full daemon restart clears those.

Ping only tests network reachability — it doesn't test whether the FlexLM daemon is listening on the correct port. Error -96 means the client can't reach the license daemon process itself. Check three things: is the daemon running on the server (ps aux | grep lmgrd)? Is port 27000-27009 open in the firewall? Does your local ANSYSLMD_LICENSE_FILE or LM_LICENSE_FILE environment variable point to the correct hostname? A recent server IP change or hostname rename breaks all clients simultaneously.

Yes — lmutil lmstat -a -c port@hostname lists all checked-out licenses without consuming any. It also shows whether the vendor daemon (e.g., abaquslm or ansyslmd) is running separately from the main lmgrd daemon. If lmgrd responds but the vendor daemon is down, you get Error -96. Also try telnet license-server 27000 — if it connects, the port is open; if it immediately closes, the daemon isn't listening.