dima333a
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
KChernov
Цитата:| Да и не всегда логично собирать все константы в одном модуле, а делать заплаточное решение не хочется |
Я сечас работаю с коммерческой программой с открытым кодом ( по крайне мере большей его частью) Программа позволяет симулировать различные физические явления, т.е. теплоперенос, гидродинамика, химические реакции, кристализация, механическая деформация... и так далее. Естественно можно симулировать все сразу или в любых физически возможных комбинациях. Количество переменных и массивов просто огромное. Соответственно каждый отдельный модуль имеет свой собственный хидер файл. Например часть кода ответственная за решение теплопшереноса имеет хидер файл "heat.fh" . Если мне гдето не хватает заданных переменных относяшихся к решению теплопереноса, я просто вначале подпрограммы пропишу:
INCLUDE 'heat.fh'
Все. Естественно хидер файлов может быть несколько, соответственно все глобальные переменные (которые вы используете не только в локально в подпрограмме) прописанны в хидерах и отсортированны по физическому смыслу. Так что зря вы жалуетесь на нелогичность. Не нравится собирать все константы в одном файле, зделайте несколько. Рассортируйте как вам удобно. При желании весь проэк можно разбить на папки. В одной папке хидеры, в другой папке только вайлы решателя, в третей файлы расчета тепла,... и так далее....
Цитата:| В моих задачах размерности могут меняться, а задавать так все возможные варианты - не выход. |
Ну хороше, не нравятся константы, задайте как переменные, запихните их в common block совместно с SAVE стайтментом и все это в хидере.
Но только недавно вы говорили что вы хотите массывы задавать через параметр... Ну и если вам нужны переменные границы массива то вы либо чегото вырезаете или меняете форму массива, и небойсь еще и динамически задаете массив как allocatable. Иначе при чем здесь переменные размеры массива???
На использование хидера(ов) это не как не влияет. Из за использования SAVE переменные измененные в подпрограмме в commmon блоке будут сохранятся. Соответственно ничего не надо передавать из подпрограммы в основную программу и назад. Вся передача данных через common block, прописанный в хидере.
Пример использования хидеров я уже давал.... Но если массив переменных размеров и динамически задаваемый... то тут нюансов я сам не представляю... Наверно можно зделать так:
! файл bounds.fh
INTEGER Amin,Amax
INTEGER Bmin,Bmax
INTEGER Cmin,Cmax
COMMON /bounds_d/ Amin,Amax,Bmin,Bmax,Cmin,Cmax
SAVE /bounds_d/
! конец файла bounds.fh
PROGRAM testB
implicit none
include 'bounds.fh'
real, allocatable d
! Задаем размеры массива ( можно и расчитать....)
Аmin=-5
Amax=5
Bmin=0
Bmax=10
Cmin=-1
Cmax=1
! allocate array in memory
allocate (d(Amin:Amax,Bmin:Bmax,Cmin:Cmax))
! Передаем массив в подрпрограмму:
! границы передавать нет необходимости
call podrpr(d)
deallocate(d)
END
SUBROUTINE podrpr(d)
implicit none
include 'bounds.fh'
real d(Amin:Amax,Bmin:Bmax,Cmin:Cmax)
! операции внутри подпрограммы
return
Думаю что работать будет. Можно еще использовать module. S.Chapman писал про это с одной из своих книженций... типа "Sharing data using modules" Но тут я уже не советчик. Самому интересно почитать. |
Всего записей: 798 | Зарегистр. 27-02-2004 | Отправлено: 17:25 03-05-2005 | Исправлено: dima333a, 17:35 03-05-2005 |
|
. С другой стороны решатель был использован Gauss-Seidel - там нет необходимости в двумерной индексации, i*J элементов, i*j уравнений. Соответственно я теже массивы использовал с как одномерные 
