Дек 13
Роман, небольшой вопрос не по теме, но может вы с такой же проблемой уже встречались. Когда я паршу SMSPEC файл, то во время парсинга в секции "KEYWORDS" мне попадается непечатная последовательность [ETX]H[SOH]X
Вы не в курсе, что это за прикол?
П.С.
Файл сгенерен эклипсом
Опубликовано
24 Дек 2013
Активность
14
ответов
5052
просмотра
3
участника
0
Рейтинг
MView/Model/DataSMSPEC.cs ответит на вопрос твой, йойо. Подсказывает интуиция мне, что твоя последовательность есть четыре байта, которые идут перед каждым считыванием из файла. Также окончание считывания завершается четырьмя байтами. Чисел суть проста - перед данными идёт значение байтов количество, считанное которое ожидается, и по окончанию фактическое число записанных байтов. Сие тугоумие есть наследие от Фортрана древнего и есть мусор. Также наследием геморным является чужеродный процессорам x86 порядок записи байт, не с того конца яйца. Мне гугл помог найти ответ в то время. А что Алексу ответить не знаю.
Вот есть пример к словам моим путанным
Четыре байта в начале и в конце пропускаю. Если не пропускать, надо сравнить эти два числа и если они не равны это повреждение при записи файла.
public void ReadEclipseHeader(ref EclipseHeader header)
Ага, спасибо Роман, сейчас посмотрю код. А биг/литл ендиан я по первым четырем байтам файла определяю. должно быть 16.
16 это есть (смотри мой пример кода) 8 байт срока +4 байта int32 + 4 байта строка. Следующее число должно быть тоже 16.
Все, вроде разобрался. Файл парсится. Роман, я ввел вас в заблуждение с числом 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]) на несколько частей
Вы сами придумали обозначения блокам или есть какая-то информация? В эклипсе действительно замысловатый подход по длинным блокам данным. А по ендианам, вроде только единственный вариант возможен, что-то проверять разве имеет смысл?
есть такое дело, я парсер под единичный файл вывода писал (а не россыпью) и пришлось обрабатывать такой момент.
Роман, информация о формате получена эмпирическим путем и возможно не совсем точна. Касательно big/little endian. На некоторых платформах, числа будут сохранены в little endian, на некоторых в big endian (для строк это не принципиально). Важно это принимать во внимание иначе можно получить мусор вместо данных. Для определения типа, можно прочесть первые 4 байта заголовка, [sync] в моей терминологии. У эклипса, это всегда должно быть число 16 в десятичной системе (00 00 00 10 в шестнадцатеричной). Если прочитанное число не 16, надо поменять представление и попробовать еще раз, если опять не 16, делаем вывод что файл испорчен.
Можешь сказать, что это за платформы, поддерживает ли их slb и встречались ли они тебе?
Роман, я ж не модельер, мне вообще любые эклипсовские файлы редко встречаются :)
Но что знаю, скажу :)
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) Еще мой бывший сослуживец говорил, что ему встречались файлы, в которых после заголовка и данных, следующий заголовок начинался не сразу, а между ними были напиханы нули. Вроде бы это не шлюмовский стиль, но тем не менее такое тоже встречается
Очень интересно, где это немодельеру потребуется ковырять эклипс.
У меня windows only, поэтому подвоха я не жду.
Роман, а Вы случайно не знаете, что это за шткука ":+:+:+:+" в "WGNAMES" секции?
Да, и еще вопрос от профана. Еклипс сохраняет состояние процесса моделирования в определенные моменты времени - ministeps в эклипсовской терминологии. А еще есть reportsteps, моменты времени когда пользователь хочет сохранить состояние процесса моделирования. Внимание вопрос! Где эти reportsteps задаются(в какой секции датафайла) и как они связаны с ministeps. Спасибо
Нашел в датафайле то, что мне нужно
-- Simulation start date
START
1 JAN 2007 /
-- Number and size (days) of timesteps
TSTEP
10*200 /
Значение START также есть и в SMSPEC файле, но я до сих пор не понимаю, как мне определить моменты времени в которые пользователь хочет иметь графики только по SMSPEC и UNSMRY файлам? Где эта информация храниться? Другими словами, как определить какой ministep является reportstep? Пробовал открыть UNSMRY файл, Роминой тулзой и Текплот РС, показывают разные наборы дат. Что делать?
Привет йойо, ты так и не ответил на кой хер тебе понадобился эклипс.
По министепам достаточно просто - в файле записаны друг за другом данные, перед которыми записывается кажется параметр MINISTEP, если он равен 0 это RESTART, большие значения показывают уже промежуточные шаги между заданными датами. Дата определяется просто, по вектору TIME, который показывает дней с начала расчёта. Комбинация +:+:+: относится к самому расчету, обычно к нему относится и TIME DAYS и времени с начала расчёта, то что не относится к скважинам.
С датами я не могу пояснить, вопрос не ясен. Может дело в том, что рестарт например на 01.10.2013 это не совсем десятый месяц, это данные девятого месяца, поэтому кто то может делать коррекцию.
Роман, спасибо за ответы.
Итак, я попробую суммировать, что знаю на данный момент, а знающие люди поправьте если не прав где-то. Только что распарсил UNSMRY файл, он имеет такую структуру :
(SEQHDR / MINISTEP / PARAMS)...(SEQHDR / MINISTEP / PARAMS), т.е повторяются эти три секции. Первая вроде не очень интересна, в то время как вторая - MINISTEP показывает номер шага. По умолчанию начинается с 0 (если использовался restart файл, возможно будет другое значение) и потом каждый следующий MINISTEP на единицу больше. Для того, что бы по номеру MINISTEP определить конкретный день/год, нужно посмотреть в соответствующую секцию PARAMS, первые два значения это "TIME" и "YEARS". Теперь о том, что мне не очень ясно. MINISTEP как я понял, это просто моменты времени, в которые Эклипс делал дискретизацию для решения диф. уравнения (другими словам это точки разностной схемы). Но пользователь то просил вывести ему результаты в другие моменты времени (START, TSTEP комманды в дата файле)? Причем я не уверен, что эти пользовательские моменты времени хранятся в SMSPEC/UNSMRY файлах? Или я не прав?
П.С.
По поводу зачем мне ковырятся в Эклипсе. Просто так сложилась жизнь, что я некоторое время работал программистом в SPTGroup (ныне это Шлюм), разрабатывал MEPO. С тех времен осталось несколько идей, которые я сейчас пытаюсь реализовать.
Спасибо
Максим aka yoyoyo :)