Иными словами, если я правильно понял, есть как минимум два варианта организации визуализации данных:

• Разработать графическую библиотеку для отображения графиков и прочего гламура. При этом она имеет интерфейс наподобие Array Viewer. Используется для этого дела С++, позволяющий реализовать это в объектно-ориентированном стиле и легче использовать графические библиотеки низкого уровня, например, OpenGL.
  Основная ррограмма, содержащая вычислительную часть изящно пишется на Fortran. Для организации визуализации данных в программе подключается бибилиотека, ей передаются соотв. данные, она запускает свой интерфейс и проводит в нём визуализацию в виде графиков и прочее. Могут быть также различные сервисные возможности: показ матрицы данных, линий уровня, кнопочки, рюшечки...
• Вычислительная начинка пишется всё также на Fortran. Оформляется для надёжности как динамическая (DLL -- Win) или общая (Shared Lib -- Lin) библиотека (просто можно ещё использовать обмен прямо через объектные файлы, но это совсем не профессионально). Фактически, библиотека представляет собой программу без интерфейса.
  Для визуализации данных на С++ пишется интерфейсная прога. Она вызывает и управляет процедурами библиотеки, т.е. контролирует все операции. Пользователь, двигаясь по элементам интерфейса, через поля данных (labels) может задавать различные параметры (цифереки), кнопками и списками управлять режимами выполнения программы (ну, или вычислений то есть), организовывать визуализацию расчётных данных в виде графиков.

На самом деле подходы очень схожи: графика реализуется на С++, основная работа -- на Fortran. Только в первом случае подключается к проекту графическая библиотека, а во втором -- программа графического интерфейса использует процедуры основной работы, представленные в виде библиотеки.
AV (Array Visualizer) позволяет делать и то и другое. Вот как эти две концепции реализуются с помощью него:

• Создаётся консольное приложение на Fortran. Оно проводит вычисления и всю основную работу. По мере необходимости или в конце своей работы она подключается к Array Visualizer и запускает экземпляр окна Array Viewer, в котором и проводится визуализация данных. Всю административную работу проводит приложение Fortran, которое является основным.
• Создаётся приложение с графическим интерфейсом, скажем, на языке С++. На форме расположены все необходимые элементы управления, в частности, и элемент ActiveX отображения графиков Graph, который идёт вместе с AV. Вся основная работа программируется в виде процедур Fortran и зашивается в библиотеку DLL. Интерфейсная прога рулит процедурами этой библиотеки. Пользователь, гуляя по форме, приказывает сосчитать что-нить, задаёт параметры, выводит графики. В большинстве случаев элементы управления, такие как кнопки, вызывают на выполнение соотв. процедуры DLL-ки, пеердавая ей параметры с формы. В файл сносятся все вычисления. После завершения из файла данные отображаются на форме. Таким образом, интерфейс здесь выполняет адвминистративные функции и является основным приложением.

Я реализовывал оба подхода. Только для второго и интерфейс писал на Fortran.
Скажу больше: сам Array Viewer написан с использованием тех же элементов ActiveX, что кидаются на формочку и идут вместе с AV (Graph и т.д.). Фактически это интерфейсное приложение, но обычно упраляют им, а не оно ходом вычислений.

Недостатки

• Граф. библиотека
  • Меньшая гибкость интерфейсных сервисов -- некоторая шаблонность интерфейса.
  • Процесом вычислений управляет стороннее, консольное приложение, а не через интерфейс.
  • Плохая возможность задания параметров и самих функций (y = x*x) с помощью интерфейса.
  • Требуется обеспечить API граф. библиотеки.
• Интерфейсная программа
  • Всем рулит интерфейсная прога, которая обязана дружить с Fortran.
  • Требуется написать элементы управления типа Graph для интеграции на форме.

Достоинства

• Граф. библиотека
  • Пишется один раз, всерьез и надолго ("... но не навсегда" (С) Ленин, по-моему).
  • Всем рулит Fortran, который на короткой ноге со своими же процедурами.
• Интерфейсная программа
  • Всем рулит интерфейсная прога, которая обеспечивает интерактивность и упралет процессом.
  • Большая гибкость разработки интерфейсов.
  • Различные параметры и ход работы задаются через граф. интерфейс.

Ещё одна фичя: можно во время вчислений отображать ход процесса в виде progress bar. Только в первом случае нужно будет создать два доп. потока -- один считает, другой параллельно отслеживает ход и отображает, а во втором -- всего один доп. поток, который считает (отслежку осуществляет сам основной поток интерфейсного приложения).

Ещё особнаком стоит вопрос кроссплатформенности. Так, например, AV есть только под виндами. Интерфейсное приложение как и граф. библиотека должны быть кроссплатформенными. Есть несколько вариантов:

• Java -- замучаемся вызвывать Fortran транзитом через обёртки на С++ (Java только С++ вызывать умеет).
• OpenGL. Можно. Но придётся довольствоваться её средствами по созданию GUI.
  Плюс здесь прокатывает только первый вариант -- с граф. библиотекой. Ведь если написать интерфейсное приложение на OpenGL, то какую основную библиотеку потом оно должно будет вызывать: DLL или Shared? Даже на уровне исходных кодов DLL и Shared будут различаться, а значит переносимости и такой не будет.
  А вот, чобы вызвать граф. бибилиотеку код нужно будет писать один и тот же. Хотя, это как ещё API её организовать...  
• .Net. Не до конца понимаю.
  C библиотекой как? По идее можно. Она оформлена как сборка .Net. С помощью Intel Wizard генерим к ней интерфейсые модули на Fortran и с помощью них вызываем её потом из Fortran. Делается это одинаково под любыми платформами.
  Для второго варианта. Допустим интерфейс вызывает DLL. А под Linux он сможет это сделать? ф.з.

В общем, есть причины тут стать мозголомом    

Во-первых, мне нужна кросссистема, а значит AView не подходит.
Во-вторых, я не сторонник во время вычислений делать иной вывод, чем консольный, и то дискретно. Т.к. операции в/в - это львиная доля работы программы. Данные должны визуализироваться до или после, если не требуется вмешательство пользователя.
Вот как лучше организовать такой обмен между интерфейсом на C++ и вычметом на Ф - это вопрос. Имеется ввиду с макс. эффективностью. 

Вот и я про это. Мне даже интересно стало, что же используют Linux-программисты для визуализации данных. 
Другой вопрос: само основное приложение должно быть кроссплатформенным? По идее, хорошо бы, чтобы да.
А сам AV я привёл как пример. К тому же его судьба сейчас не понятна: толи open source, то ли останется freeware без поддержки и обновлений.

Сам я имел в виду интерактивный процесс управления процессом какого-нибудь исследования. Например, задаешь на формочке параметры, прога считает, визуализирует, что-то меняешь из параметров, опять считает и визуализирует и т.д.

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

Думаю, как и при работе AV: в процедуру на C++ передаётся по ссылке матрица сосчитанных данных, например, трёхмерная, по ней строится поверхность. Саму аппрокимацию и вывод делает, естественно, С++ процедура. Или С++ интерфейс обращается к процедуре на Fortran, куда кроме всего прочего подставляется матрица. После завершения работы процедуры в матрице необходимые данные для визуализации.

P.S. Слово "мозголом" взял из передачи на Ren-TV, потому употреблял в ироничном смысле.   

Во-во. Полностью согласен. А пока выкладываю архив с тем, что наваял. Правда пока параметры из интерфейса не меняются, но все же разобрался я с QWin. После Builder'a и QT терпеть не могу процедурное программирование графики - всякие там WinAPI. Скорей бы уж Ф2003-компилятор вышел - тогда бы таких проблем не было бы. Только боюсь, что он к 2009 году выйдет, когда надо будет уже Ф2009 делать для ISO C++2009  
Только архив не пихается: вот ссылка http://popov-512.narod.ru/books/AnalisOfTraectory.rar 

Да. Надеюсь, их не будет. Ведь объекты Fortran тоже незаурядная вестчь. Всё хочу привести в Forki инфу о средствах F03, да когда этим всем заняться  

Ой, и не говори. Хотя, F03 поддерживает C99, возможно, в следующем стандарте будет реализована поддержка C++09. Кто знает...
А пока в качетсве оффтопа имеем следующие средства F03 в IVFC 9.1:

• GET_COMMAND intrinsic 
• GET_COMMAND_ARGUMENT intrinsic 
• COMMAND_ARGUMENT_COUNT intrinsic 
• GET_ENVIRONMENT_VARIABLE intrinsic 
• Allocatable components of derived types 
• Allocatable dummy arguments 
• Allocatable function results 
• VOLATILE attribute and statement 
• Names of length up to 63 characters 
• Statements up to 256 lines 
• A named PARAMETER constant may be part of a complex constant 
• In all I/O statements, the following numeric values can be of any kind: 
• UNIT=, IOSTAT= 
• The following OPEN numeric values can be of any kind: RECL= 
• The following READ and WRITE numeric values can be of any kind: REC=, SIZE= 
• The following INQUIRE numeric values can be of any kind: NEXTREC=, NUMBER=, RECL=, SIZE= 
• Recursive I/O is allowed when the new I/O being started is internal I/O that does not modify any internal file other than its own 
• IEEE infinities and Nans are displayed by formatted output as specified by Fortran 2003 
• In an I/O format, the comma after a P edit descriptor is optional when followed by a repeat specifier 
• The following intrinsics take an optional KIND= argument: ACHAR, COUNT, IACHAR, ICHAR, INDEX, LBOUND, LEN, LEN_TRIM, MAXLOC, MINLOC, SCAN, SHAPE, SIZE, UBOUND, VERIFY 
• Square brackets [ ] are permitted to delimit array constructors instead of (/ /) 
• The Fortran character set has been extended to contain the 8-bit ASCII characters ~ \ [ ] ` ^ { } | # @ 
• User-defined operators can be renamed in USE statements 
• MOVE_ALLOC intrinsic subroutine 
• PROTECTED attribute and statement 
• Pointer objects can have the INTENT attribute

Ближе всего к стандарту продвигается NAG, часть команды разработчиков которого состоят в комитете по стандартизации Fortran. Собственно, даже родной сайт этого комитета расположен на их сервере.
Твой проект прикрепил к моему посту, чтобы сохранился. Своё обсуждение по нему я приведу позже. В прежней теме пускай, например, другие примеры приводят для CVF.  

Это сообщение отредактировал(а) Cr@$h - 12.7.2006, 22:59

Присоединённый файл ( Кол-во скачиваний: 6 )
 AnalisOfTraectory.rar 43,50 Kb

Значит NAG. Надо влезть, взглянуть. Подумем и над IFC. Спасибо за информацию. А то я все это отслеживать не успеваю. Мне вынь да положь готовый Ф03-компилятор 

Он нормальный такой. Можно посмотреть на нашем любимомPolyhedron. Numeric Analys Group делает хорошие библиотеки численных методов.

О, хорошо бы создать тему "Ход реализации компиляторов Fortran 2003 | Новости об уже реализованные средства стандарта". Кто захочет, может кидать туда соотв. инфу по любому компилятору.