парсинг SMSPEC файла

Последнее сообщение
yoyoyo 134 8
Дек 13

Роман, небольшой вопрос не по теме, но может вы с такой же проблемой уже встречались. Когда я паршу SMSPEC файл, то во время парсинга в секции "KEYWORDS" мне попадается непечатная последовательность [ETX]H[SOH]X
Вы не в курсе, что это за прикол? 
П.С.
Файл сгенерен эклипсом

RomanK. 2163 13
Дек 13 #1

MView/Model/DataSMSPEC.cs ответит на вопрос твой, йойо. Подсказывает интуиция мне, что твоя последовательность есть четыре байта, которые идут перед каждым считыванием из файла. Также окончание считывания завершается четырьмя байтами. Чисел суть проста - перед данными идёт значение байтов количество, считанное которое ожидается, и по окончанию фактическое число записанных байтов. Сие тугоумие есть наследие от Фортрана древнего и есть мусор. Также наследием геморным является чужеродный процессорам x86 порядок записи байт, не с того конца яйца. Мне гугл помог найти ответ в то время. А что Алексу ответить не знаю.

Вот есть пример к словам моим путанным
Четыре байта в начале и в конце пропускаю. Если не пропускать, надо сравнить эти два числа и если они не равны это повреждение при записи файла.
public void ReadEclipseHeader(ref EclipseHeader header)

        {
            ReadBytes(4);
            header.keyword = ReadString(8).Trim();
            header.count = ReadInt32();
            header.type = ReadString(4);
            ReadBytes(4);
        }
yoyoyo 134 8
Дек 13 #2

Ага, спасибо Роман, сейчас посмотрю код. А биг/литл ендиан я по первым четырем байтам файла определяю. должно быть 16.

RomanK. 2163 13
Дек 13 #3

16 это есть (смотри мой пример кода) 8 байт срока +4 байта int32 + 4 байта строка. Следующее число должно быть тоже 16.

yoyoyo 134 8
Дек 13 #4

Все, вроде разобрался. Файл парсится. Роман, я ввел вас в заблуждение с числом 16. 
Формат эклипсовского файла такой 
{[sync][keyword][data_count][data_type][sync]}[data_block]
а в свою очередь [data_block] вот такая структура ([sequence_size_in_bytes]([data_entry])+[sequence_size_in_bytes])+
(...)+ означает 1 или более

Так вот, [sync] должен быть 16, если это не так, меняем эндиан и проверяем снова, если не 16 - файл испорчен.

А у меня проблема была в том, что эклипс разбил секцию с данными ([data_block]) на несколько частей

RomanK. 2163 13
Дек 13 #5

Вы сами придумали обозначения блокам или есть какая-то информация? В эклипсе действительно замысловатый подход по длинным блокам данным. А по ендианам, вроде только единственный вариант возможен, что-то проверять разве имеет смысл?

EmptyEye13 102 14
Дек 13 #6

yoyoyo пишет:
А у меня проблема была в том, что эклипс разбил секцию с данными ([data_block]) на несколько частей

есть такое дело, я парсер под единичный файл вывода писал (а не россыпью) и пришлось обрабатывать такой момент.

yoyoyo 134 8
Дек 13 #7

Роман, информация о формате получена эмпирическим путем и возможно не совсем точна. Касательно big/little endian. На некоторых платформах, числа будут сохранены в little endian, на некоторых в big endian (для строк это не принципиально). Важно это принимать во внимание иначе можно получить мусор вместо данных. Для определения типа, можно прочесть первые 4 байта заголовка, [sync] в моей терминологии. У эклипса, это всегда должно быть число 16 в десятичной системе (00 00 00 10 в шестнадцатеричной). Если прочитанное число не 16, надо поменять представление и попробовать еще раз, если опять не 16, делаем вывод что файл испорчен.

RomanK. 2163 13
Дек 13 #8

Можешь сказать, что это за платформы, поддерживает ли их slb и встречались ли они тебе?

yoyoyo 134 8
Дек 13 #9

Роман, я ж не модельер, мне вообще любые эклипсовские файлы редко встречаются :)
Но что знаю, скажу :)
1) Я как-то работал с парнем, он писал диссертацию связанную с Ensemble Kalman filter, и ему приходилось парсить и генерить эклипсовские файлы, так вот он утверждал, что попадаются время от времени файлы с литл эндиан. Точную статистику я не знаю, но дословно он сказал - both types actually appear in practice
2) Я сейчас посмотрел Eclipse File Format Manual, оказывается этот формат не изобретение шлюмов, а Compaq Visual Fortran формат. Век живи - век учись. И похоже ты сам можешь указать эклипсу под линуксом, как тебе сохранять числа :
On Linux systems, use of big-endian or little-endian output is selected at run time by setting an
environment variable. Так что нельза исключать такого подарка.

Вот кстати еще интересное сообщение 
http://mathematica.stackexchange.com/questions/14988/import-fortran-unformatted-binary

3) Еще мой бывший сослуживец говорил, что ему встречались файлы, в которых после заголовка и данных, следующий заголовок начинался не сразу, а между ними были напиханы нули. Вроде бы это не шлюмовский стиль, но тем не менее такое тоже встречается

RomanK. 2163 13
Дек 13 #10

Очень интересно, где это немодельеру потребуется ковырять эклипс.
У меня windows only, поэтому подвоха я не жду.

yoyoyo 134 8
Дек 13 #11

Роман, а Вы случайно не знаете, что это за шткука ":+:+:+:+"  в "WGNAMES" секции?

Да, и еще вопрос от профана. Еклипс сохраняет состояние процесса моделирования в определенные моменты времени - ministeps в эклипсовской терминологии. А еще есть reportsteps, моменты времени когда пользователь хочет сохранить состояние процесса моделирования. Внимание вопрос! Где эти reportsteps задаются(в какой секции датафайла) и как они связаны с ministeps. Спасибо

 

yoyoyo 134 8
Дек 13 #12

Нашел в датафайле то, что мне нужно

-- Simulation start date
START
    1 JAN 2007    /

-- Number and size (days) of timesteps
TSTEP
    10*200 /

Значение START также есть и в SMSPEC файле, но я до сих пор не понимаю, как мне определить моменты времени в которые пользователь хочет иметь графики только по  SMSPEC и UNSMRY файлам? Где эта информация храниться? Другими словами, как определить какой ministep является  reportstep? Пробовал открыть UNSMRY файл, Роминой тулзой и Текплот РС, показывают разные наборы дат. Что делать?

RomanK. 2163 13
Дек 13 #13

Привет йойо, ты так и не ответил на кой хер тебе понадобился эклипс.
По министепам достаточно просто - в файле записаны друг за другом данные, перед которыми записывается кажется параметр MINISTEP, если он равен 0 это RESTART, большие значения показывают уже промежуточные шаги между заданными датами. Дата определяется просто, по вектору TIME, который показывает дней с начала расчёта. Комбинация +:+:+: относится к самому расчету, обычно к нему относится и TIME DAYS и времени с начала расчёта, то что не относится к скважинам.

С датами я не могу пояснить, вопрос не ясен. Может дело в том, что рестарт например на 01.10.2013 это не совсем десятый месяц, это данные девятого месяца, поэтому кто то может делать коррекцию.

yoyoyo 134 8
Дек 13 #14

Роман, спасибо за ответы.
Итак, я попробую суммировать, что знаю на данный момент, а знающие люди поправьте если не прав где-то. Только что распарсил UNSMRY файл, он имеет такую структуру :
(SEQHDR / MINISTEP / PARAMS)...(SEQHDR / MINISTEP / PARAMS), т.е повторяются эти три секции. Первая вроде не очень интересна, в то время как вторая - MINISTEP показывает номер шага. По умолчанию начинается с 0 (если использовался restart файл, возможно будет другое значение) и потом каждый следующий MINISTEP на единицу больше. Для того, что бы по номеру MINISTEP  определить конкретный день/год, нужно посмотреть в соответствующую секцию PARAMS, первые два значения это "TIME" и "YEARS". Теперь о том, что мне не очень ясно. MINISTEP как я понял, это просто моменты времени, в которые Эклипс делал дискретизацию для решения диф. уравнения (другими словам это точки разностной схемы). Но пользователь то просил вывести ему результаты в другие моменты времени (START, TSTEP комманды в дата файле)? Причем я не уверен, что эти пользовательские моменты времени хранятся в SMSPEC/UNSMRY файлах? Или я не прав?

П.С.
По поводу зачем мне ковырятся в Эклипсе. Просто так сложилась жизнь, что я некоторое время работал программистом в SPTGroup (ныне это Шлюм), разрабатывал MEPO. С тех времен осталось несколько идей, которые я сейчас пытаюсь реализовать. 

Спасибо
Максим aka yoyoyo :)

Go to top