История изменений

Всем отписавшимся: в фортране бинарные файлы состоят из записей, причём формат записи стандартом не регламентирован. Должна быть возможность определить её длину и, наверное, возможные ошибки связанные с порчей этой самой длины (не уверен). Поэтому в зависимости от версии компилятора в начале и в конце записи добавляются дополнительные байты, которые обычно содержат длину записи. GNU и Intel просто пишут int, равный размеру записи в байтах. Отсюда четыре раза 4 в начале файла: write(341) NumResultSet пишет «4» как длину записи (один integer), «4» как значение NumResultSet и снова «4» --- длина записи. Потом то же для MaxNode, равного 7. Поэтому просто read(), unpack() работать не будет. ТС сделал правильное решение через FortanFile, но следует иметь в виду, что если FortranFile и программа скомпилирована разными компиляторами, то, вообще говоря, совместимость не гарантирована (хотя, конечно, проблемы маловероятны).

На случай если кто-то выпадет сюда из гугла, попиарю свою поделку: http://jini-zh.org/fconv/fconv.html

Всем отписавшимся: в фортране бинарные файлы состоят из записей, причём формат записи стандартом не регламентирован. Должна быть возможность определить её длину и, наверное, возможные ошибки связанные с порчей этой самой длины (не уверен). Поэтому в зависимости от версии компилятора в начале и в конце записи добавляются дополнительные байты, которые обычно содержат длину записи. GNU и Intel просто пишут int, равный размеру записи в байтах. Отсюда четыре раза 4 в начале файла: write(341) NumResultSet пишет «4» как длину записи (один integer), «4» как значение NumResultSet и снова «4» --- длина записи. Потом то же для MaxNode, равного 7. Поэтому просто read(), unpack() работать не будет. ТС сделал правильное решение через FortanFile, но следует иметь в виду, что если FortranFile и программа скомпилирована разными компиляторами, то, вообще говоря, совместимость не гарантирована (хотя, конечно, проблемы маловероятны).