Have you ever experienced a Linux solver failure with Fluent etc. when you edited the input deck or include files on a Windows workstation? If so, this post unravels the mystery of why that happens, and how to prevent it.

The Fangled Newline

In text documents lines are separated by what is called a newline, also called an end of line (EOL). Different operating systems have different invisible codes that represent this newline.

For example, on Windows the end of line is marked by a carriage return (CR) followed by a line feed (LF). On Linux/Unix, the end of line is marked only by a single line feed (LF)

This means that text documents that come from a Windows system won’t always work on Linux with your solver. Some utilities won’t show these invisible end of line characters, but sometimes you will see the CR on Linux as a bunch of ^M if you use an editor like vi.

The Problem

Here is an example of a journal file created on Windows, and is having problems with a Linux solver. I use the “cat” command on Linux, to view the file, and note it looks completely normal:

[~]$ cat test.jou
file
read-case-data/test.cas
quit


However, by adding the “-v” option I can see the special Windows end of line Carriage Return (CR) represented by ^M, this indicates this file is a WINDOWS formatted file, and will likely cause the solver to fail with strange errors:

[~]$ cat -v test.jou
file^M
read-case-data/test.cas^M
quit^M


The Fix

A simple way to fix this is issue the “dos2unix” command on Linux

[~]$ dos2unix test.jou
dos2unix: converting file test.jou to UNIX format ...

Now a quick check shows no ^M:

[~]$ cat -v test.jou
file
read-case-data/test.cas
quit


Preventing It

Instead of running dos2unix on Linux every time you edited it originally on Windows, I recommend to use the free notepad++ editor on Windows that lets you control end of line handling. In Notepad++ go to Edit->EOL Conversions->UNIX Format to edit a file and keep it in UNIX (Linux) format.

The other major way end of lines get messed up is transferring files using FTP or other transfer mechanism that changes the line feeds automatically. If you use ASCII mode when transferring with FTP, this can happen. If you always use BINARY mode by typing the word “binary” at the FTP prompt before you use GET or PUT. FTP will not try and modify the end of lines if you force BINARY mode, even though the file is ASCII, preserving the source encoding.

We will be doing a series of posts on Linux/Windows interoperability. Stay tuned!