Базы данных результатов для числовых кодов

В литературе по численным методам многие исследовательские работы состоят из описания нового алгоритмического варианта, за которым следует несколько тестовых задач, сравнивающих новый метод с одним или двумя существующими методами. Это затрудняет определение

• Как новый метод будет работать на другие проблемы, представляющие интерес
• Как новый метод будет сравниваться с другими существующими методами

Конечно, оба эти вопроса, как правило, имеют решающее значение для тех, кто решает, следует ли принять новый метод. Чтобы улучшить эту ситуацию, представляется целесообразным, если это возможно, заставить людей выполнить большой набор тестовых задач ( см. Этот вопрос ) с их методом и занести в каталог результаты в базе данных для сравнения с другими методами. Затем ученый или инженер может запросить базу данных, возможно, указав, какие характеристики решения / проблемы наиболее важны для них (точность, эффективность, качественные свойства и т. Д.), И получить количественное сравнение производительности всех методов в базе данных.

Я понимаю, что в реализации этой идеи есть много трудностей (главным образом: заставить людей реально решить все эти проблемы и измерить вычислительные затраты). Но мой вопрос: существует ли такая база данных результатов? (скажем, в каком-то конкретном подполе) или подобный подход был реализован где-нибудь?

Оба опубликованных ответа касаются баз данных проблем. Я спрашиваю о базах результатов.

Из указанных вами критериев я думаю, что самым близким из известных мне проектов будет коллекция разреженных матриц Университета Флориды . Люди обычно используют этот набор данных для сравнения разреженных решателей линейной алгебры, и вы можете фильтровать по приложениям, количеству ненулевых элементов, размерам матрицы и т. Д. С действительно хорошим веб-интерфейсом, интерфейсом MATLAB или Java GUI. Я видел таблицы этих проблем, перечисленные в статьях, а также сравнение времени выполнения решателя с 4-8 решателями линейной алгебры.

Я согласен с тем, что было бы полезно скомпилировать такие базы данных, и, кроме того, я думаю, что подход сбора разряженных матриц UF для компиляции данных является отличным, и он станет отличным началом для любого, кто задумывается о реализации этой идеи. Выполнение всех задач на практике не кажется большой трудностью, если вы можете получить доступ ко всем решателям; если у вас есть доступ к решателям и надежный стандартный эталонный компьютер со всем необходимым программным обеспечением, тогда нужно запустить скрипт и собрать данные. На мой взгляд, сложность заключается в том, чтобы заставить людей предоставить вам свое программное обеспечение, если оно не является открытым исходным кодом. Если он коммерческий, вы можете его купить или даже заставить людей пожертвовать программное обеспечение,МОНЕТА ИЛИ ПРОЕКТ. Но если это исследовательское программное обеспечение, которое не является ни коммерческим, ни открытым исходным кодом, то вам нужно убедить людей в том, что они должны вкладывать средства, и они могут не доверять третьей стороне в том, чтобы справедливо оценивать свое программное обеспечение.

Я также знаю, что в оптимизации есть загружаемые базы данных проблем ( на ум приходит CUTEr ) и книги тестовых задач для оптимизации. Я видел, как люди (например, я специально думаю о выступлении Рут Мизенер на AICHE 2011) сравнивали их решатель оптимизации с другими решателями в базах данных проблем в презентациях; Я не уверен, что публикуется публично. Я знаю, что существует традиция оптимизации для сравнения в больших масштабах (много решателей, много проблем); Я просто не думаю, что есть онлайн база данных.

Еще одна вещь, которую я считаю важной, заключается в том, что мы различаем методы и реализации программного обеспечения., В научных вычислениях мы все говорим о том, какие методы быстрее или медленнее, основываясь на таких вещах, как метрики вычислительной сложности или наш опыт решения различных проблем. Однако когда дело доходит до количественного измерения вычислительного времени, если только не подсчитано количество FLOP в конкретном алгоритме, нужно реализовать алгоритм в программном обеспечении, а затем каким-то образом измерить производительность (использование памяти, время выполнения настенных часов и т. Д. .). Имеет смысл оценивать производительность метода при рассмотрении сложности вычислений или подсчетов FLOP, потому что нам не нужна реализация для измерения таких вещей, но в тот момент, когда мы интересуемся фактическим временем работы настенных часов, разговор о методах полезно только в качестве абстрактного, разговорного устройства. (Например,

Я привел это различие между методами и программным обеспечением, потому что в такой базе данных я также мог видеть возможность отслеживания улучшений в программном обеспечении с течением времени. Так, например, с чем-то вроде, скажем, PETSc, или PyCLAW, или с любым другим программным обеспечением, которое тестируется, было бы интересно увидеть, на какие проблемы положительно (или отрицательно!) Влияют обновления программного обеспечения. Это может быть полезно для исследователей, пытающихся решить, стоит ли каких-либо потенциальных затрат денег и рабочей силы на обновление их кодов. Другая причина, по которой такое различие важно, заключается в том, что хороший метод может быть плохо реализован; Я думаю, что эта возможность способствует сдержанности, которую люди иногда имеют при обмене кодами своих исследований.

Я думаю, что бы ни исходило из этой идеи (и я надеюсь, что что-то из этого выйдет и будет готово внести свой вклад после моей докторской диссертации), важно подчеркнуть это различие между программным обеспечением и методами, потому что, если мы проводим тестовые задачи, мы будет публиковать результаты для программного обеспечения.

Была предпринята попытка создать список «сложных» интегралов для численного расчета (см. Статьи Вальтера Гаутски, Роберта Писсенса и др.), Но не было формальной базы данных.

В области ODE есть набор тестов IVP, набор тестов для проблем начальных значений.

Я не знаком с такой базой данных, но я думаю, что было бы очень трудно определить полезным способом. Лучшая система, на мой взгляд, состоит в том, чтобы выпускать код в работоспособной форме, чтобы пользователь мог расширять тестирование настолько полно, насколько ему нравится. Что касается репозиториев сообщества, то набор тестов IVP, о котором упоминает GertVdE, также содержит код драйвера для запуска нескольких опубликованных решателей ODE / DAE по тестовым задачам. В своих публикациях я пытаюсь выпустить код и все сценарии, используемые для анализа выходных данных и создания графиков и таблиц, появляющихся в статье.

Семинар по вычислительной аэроакустике по контрольным задачам имеет аналогичную цель для задач аэроакустики. Сначала они заранее представляют ряд проблем с эталонными тестами, и пусть люди решают их, используя свои собственные методы, и сравнивают результаты. Например, вот материалы четвертого совещания: http://www.archive.org/details/nasa_techdoc_20040182258

Хотя, насколько я могу судить, они не сравнивают эффективность своих кодов друг с другом, в основном они смотрят на точность.

В моделировании землетрясений было предпринято несколько таких попыток. На ум приходят проект моделирования динамического разрыва и проект инверсии источника (http://eqsource.webfactional.com/wiki/). Оба из них предоставляют физические проблемы для решения и являются агностиком (на некотором уровне) относительно используемых методов. На самом деле эти проекты направлены на то, чтобы дать возможность разработчикам моделей доменов сравнивать друг с другом, а на самом деле это не общий набор тестовых задач для каждого числового метода pdes. Но вы можете сравнить с другими результатами, и это выявило много проблем со многими кодами.

Одной из возможностей взглянуть на это будет проект Мадагаскар , который был разработан в мире сейсмических изображений, но претендует на вполне общее назначение.