Хорошие практики для форматирования вывода симуляции

Question

Это почти вопрос программирования, но он ориентирован на физиков.

Предположим, я пишу программный продукт, который принимает в качестве входных данных некоторые системные параметры, а затем вычисляет что-то из него, в моем случае спектральную функцию $ A (k, \ omega) $.

Когда я хочу просто взять вывод и передать его в gnuplot, я должен сделать так, чтобы программа выводила простую таблицу с одним столбцом для значений $ k $, одним для $ \ omega $ и одним для $ A (k , \ Omega) $.

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

Я не хочу постоянно взламывать исходный код в зависимости от того, какой вывод я хочу. Было бы лучше, если бы all соответствующие данные "run" были бы представлены в одном файле / объекте, но так, чтобы все еще было легко извлечь таблицы, которые я могу передать gnuplot.

Не желая изобретать велосипед и разрабатывать полноценный формат файла, существуют ли какие-то «стандарты», которые лучше всего использовать при создании, обработке и хранении данных из расчетов или моделирования? Может быть, даже в формате базы данных SQL?

Answer 1

Есть десятки методов, и ни один из них не слишком хорош;Я поделюсь двумя моими:

1. Если программа того стоит, я добавлю небольшой парсер конфигурационных файлов.Затем я просто делаю cofig, скажем, SimA.in, и симулятор создает группу файлов с соответствующими данными SimA.paths, SimA.stats, SimA.log и т. Д. Если имена не являются уникальными, и я добавляю версию кодадля регистрации это делает результаты полностью воспроизводимыми, а само моделирование достаточно переносимым, чтобы им было легко управлять.
2. Если нет, я просто немного обертываю код и использую R в качестве хоста.Затем я просто возвращаю все массивы и скаляры (структуры данных R очень гибкие, и легко создавать собственные структуры R или C) и использую R для управления, сохранения / загрузки и, конечно, визуализации и анализа данных.Более того, с помощью Sweave и CacheSweave все выполнение, анализ и отчетность могут быть объединены в элегантный пакет, полностью воспроизводимый одной командой.

Если вам нужно «корпоративное» решение, попробуйте NetCDF или HDF5 .Но я чувствую, что это может быть излишним.

И, конечно, контроль версий кода симулятора является обязательным.Но это очевидно =)

Answer 2

Для проекта, над которым я сейчас работаю, использующего Python и C ++ (через SWIG), я планирую использовать короткий скрипт Python в качестве входного файла. Так что, в некотором смысле, я буду «взламывать источник» для изменения параметров, но на интерпретируемом языке, а не на скомпилированном.

В настоящее время я планирую иметь входной файл типа parameters.py и использовать его как from parameters import params. Но это может быть слишком зависит от правильного синтаксиса.

params = {
"foods" : ["spam", "beans", "eggs"],
"costs" : [199, 4, 1],
"customerAge" : 23,
}

Другой вариант может состоять в том, чтобы просто определить переменные на уровне скрипта в parameters2.py. Это теряет красивую упаковку словаря, но делает его немного более сложным для пользователя. И, вероятно, было бы нетрудно написать «парсер», который помещает эти переменные уровня скрипта в хороший словарь. Плюсом метода является то, что пользователь может параметризовать вещи, которые изначально не рассматривались - from parameters2 import * перезапишет предыдущие определения этих параметров. Конечно, это может быть плохо, если пользователь перезаписывает что-то важное.

foods = ["spam", "beans", "eggs"]
costs = [199, 4, 1]
customerAge = 23

parameters3.py будет использовать класс, хотя это противопоказано проницательностью Python по поводу отступов. from parameters3 import params

class params:
    foods = ["spam", "beans", "eggs"]
    costs = [199, 4, 1]
    customerAge = 23

Для полноты картины также следует отметить, что наш код C ++ также определяет класс параметров. То есть в нашем реальном проекте файл parameters.py является оболочкой SWIG для соответствующего класса C ++. Вы бы использовали как from parameters4 import params. Однако это позволяет использовать только те параметры, которые уже объявлены в классе C ++.

import parameters
params = parameters.Parameters()
params.foods = ["spam", "beans", "eggs"]
params.costs = [199, 4, 1]
params.customerAge = 23