-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathPARAM.XML
1821 lines (1513 loc) · 67.8 KB
/
PARAM.XML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!-- The syntax is described by share/Scripts/CheckParam.pl and the manual -->
<commandList name="Control Module">
CON reads input parameters from the PARAM.in file and the files
included into PARAM.in. All commands interpreted by CON start
with the # character followed by capital letters and numbers.
The commands can have an arbitrary number of parameters,
which are written into the lines following the command.
Other lines are ignored, and can be used for remarks.
The general format of the parameter file is
#COMMANDNAME1
variable1
variable2
#COMMANDNAME2
#COMMANDNAME3
variable3
The #BEGIN_COMP ID and #END_COMP ID commands are exceptional in the sense
that their parameters are written in the same line as the command itself.
This exception makes the parameter file more readable. The parameter
is the two-character component ID. There must be exactly one space
between the #BEGIN_COMP or #END_COMP string and the ID.
The lines between the #BEGIN_COMP ID and the matching
#END_COMP ID commands are passed to the component with the
corresponding ID. For example
#BEGIN_COMP GM
#AMR
-1
#END_COMP GM
The parameters passed to the components can be of arbitrary format.
The only restriction is that the length of the lines cannot exceed
100 characters (extra characters will be ignored).
<!-- Initial defaults which are needed for rules -->
<set name="IsTimeAccurate" type="logical" value="T" />
<commandgroup name="GENERAL COMMANDS">
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!! GENERAL COMMANDS !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<command name="INCLUDE">
<parameter name="NameIncludeFile" type="string"
default="RESTART.in" length="100" />
#INCLUDE
RESTART.in NameIncludeFile
The NameIncludeFile parameter contains the name of the file to be included.
The file name may be followed with a trailing comment if it
is separated with at least 3 spaces or one TAB character.
The #INCLUDE command can be used anywhere in the parameter file,
even in the sections which contain the component specific parameters.
For example the information in the run/GM/restartIN/restart.H
file or parameters specific to a component can be included.
</command>
<command name="END">
#END
The #END command signals the end of the included file or the
end of the PARAM.in file. Lines following the #END command are
ignored. It is not required to use the #END command. The end
of the included file or PARAM.in file is equivalent with an
#END command in the last line.
</command>
<command name="STRICT" multiple="T">
<parameter name="UseStrict" type="logical" default="T" />
#STRICT
T UseStrict
If UseStrict is true, the SWMF does not attempt to correct problems,
but it stops after the warning message. If it is set to false, SWMF
attempts to correct the problems after the warning message is issued.
It is possible to switch back and forth between strict and non-strict mode.
A typical use is to switch off strict mode when a component is switched off
in a session so some of the processors are idling. Once all processors are
used, it is a good idea to switch back to strict mode.
The default is strict mode.
</command>
<command name="DESCRIPTION" multiple="T">
<parameter name="StringDescription" type="string" length="400" />
#DESCRIPTION
This is a test run for GM-IE-UA coupling.
The StringDescription string can be used to describe the simulation
for which the parameter file is written. The #DESCRIPTION command and
the StringDescription string are saved into the restart file,
which helps in identifying the restart files.
The default value is "Please describe me!", which is self explanatory.
</command>
</commandgroup>
<commandgroup name="TIME AND SESSION CONTROL">
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!! TIME AND SESSION CONTROL !!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The execution of SWMF is done in consecutive sessions. Each session is
executed with a set of parameters read from the parameter file.
After the session is finished, CON reads and distributes the parameters for
the next session. Parameters from previous sessions are carried over,
so only the changes relative to the previous session need to be given.
<command name="RUN">
<set name="_STOP" type="logical" value="F"/>
#RUN
The #RUN command does not have any parameters. It signals the end
of the current session, and makes CON execute the session with
the current set of parameters. The parameters for the next session
start after the #RUN command. For the last session there is no
need to use the #RUN command, since the #END command or simply
the end of the PARAM.in file makes CON execute the last session.
</command>
<command name="TIMEACCURATE">
<parameter name="IsTimeAccurate" type="logical" default="T" />
#TIMEACCURATE
F IsTimeAccurate
If IsTimeAccurate is set to true, the SWMF is solving
a time dependent problem. If IsTimeAccurate is false, a steady-state
solution is sought for. It is possible to use steady-state mode
in the first few sessions to obtain a steady state solution,
and then to switch to time accurate mode in the following sessions.
In time accurate mode the frequency of coupling, saving restart files,
or stopping conditions are taken in simulation time, which is the
time relative to the initial time. In steady state mode the simulation
time is not advanced at all, instead the time step or iteration number
is used to control the frequencies of various actions.
The steady-state mode also allows the components to use various
acceleration techniques. For example the BATSRUS code (in the GM, IH, SC
components) can use local time stepping to accelerate convergence
to steady state. In steady state mode the various components
are allowed to use different number of iterations per global iteration,
thus they can converge to steady state more optimally (see the #CYCLE command).
The default value is the time accurate mode.
</command>
<command name="STARTTIME" if="$_IsFirstSession" multiple="T">
<parameter name="iYear" type="integer" default="2000" />
<parameter name="iMonth" type="integer" min="1" max="12" default="3"/>
<parameter name="iDay" type="integer" min="1" max="31" default="21"/>
<parameter name="iHour" type="integer" min="0" max="23" default="0"/>
<parameter name="iMinute" type="integer" min="0" max="59" default="0"/>
<parameter name="iSecond" type="integer" min="0" max="59" default="0"/>
<parameter name="FracSecond" type="real" min="0" max="1" default="0"/>
#STARTTIME
2000 iYear
3 iMonth
21 iDay
10 iHour
45 iMinute
0 iSecond
0.0 FracSecond
The #STARTTIME command sets the initial date and time for the
simulation in Greenwich Mean Time (GMT) or Universal Time (UT).
This time is stored in the restart files. It can be overwritten
with another #STARTTIME command if necessary.
The default values are shown above. This is a date and time when, for
the Earth, both the rotational and the magnetic axes have
approximately zero tilt towards the Sun.
</command>
<command name="ENDTIME">
<parameter name="iYear" type="integer" default="2000" />
<parameter name="iMonth" type="integer" min="1" max="12" default="3"/>
<parameter name="iDay" type="integer" min="1" max="31" default="21"/>
<parameter name="iHour" type="integer" min="0" max="23" default="0"/>
<parameter name="iMinute" type="integer" min="0" max="59" default="0"/>
<parameter name="iSecond" type="integer" min="0" max="59" default="0"/>
<parameter name="FracSecond" type="real" min="0" max="1" default="0"/>
<set name="TimeMax" type="real" value="0"/>
<set name="_ENDTIME" type="logical" value="1"/>
#ENDTIME
2000 iYear
3 iMonth
22 iDay
10 iHour
45 iMinute
0 iSecond
0.0 FracSecond
This command can only be used in time accurate mode and in the final session.
The #ENDTIME command sets the date and time in Greenwich Mean Time
(GMT) or Universal Time (UT) when the simulation should be ended.
This is an alternative to the #STOP command in the final session.
This time is stored in the final restart file as the start time for
the restarted run, and the tSimulation parameter of the #TIMESIMULATION
and the nStep parameter of the #NSTEP commands are set to zero.
This avoids accumulation of tSimulation or nStep for continuously
restarted runs.
There is no default value.
</command>
<command name="TIMESIMULATION" if="$_IsFirstSession" multiple="T">
<parameter name="tSimulation" type="real" min="0" default="0.0" />
#TIMESIMULATION
1 hour tSimulation [sec]
The tSimulation variable contains the simulation time in seconds
relative to the initial time set by the #STARTTIME command.
The #TIMESIMULATION command and tSimulation are saved into the restart file,
so that the simulation can continue from the same time when the
restart was saved. It can be overwritten
with another #TIMESIMULATION command if necessary.
The default value is tSimulation=0.
</command>
<command name="NSTEP" if="$_IsFirstSession" multiple="T">
<parameter name="nStep" type="integer" min="0" default="0" />
#NSTEP
100 nStep
The nStep variable contains the number of time steps since the
beginning of the simulation (including all restarts).
The #NSTEP command and the nStep variable are saved into the restart file,
so that the simulation can continue from the same time step when
the restart was saved. It can be overwritten with another #NSTEP
command if necessary.
The default value is nStep=0.
</command>
<command name="STOP">
<parameter name="MaxIter" type="integer" min="-1" default="-1" />
<parameter name="TimeMax" type="real" min="-1" default="-1" />
<set name="_STOP" type="logical" value="T"/>
#STOP
100 MaxIter
1.5 hour TimeMax
The MaxIteration variable contains the
maximum number of iterations {\it since the beginning of the current run}
(in case of a restart, the time steps done before the restart do not count).
If nIteration reaches this value the session is finished.
The tSimulationMax variable contains the maximum simulation time
relative to the initial time determined by the #STARTTIME command.
If tSimulation reaches this value the session is finished.
Using a negative value for either variables means that the
corresponding condition is not checked. If TimeMax is negative
in time accurate mode or MaxIter is negative in steady state mode,
the code stops with an error message. If the values are set to zero,
the code will run and stop as normal, but not advance the solution.
The #STOP command must be used in every session. The only exception is the last
session, where the #ENDTIME command can be used instead of #STOP in
time-accurate mode.
If the code completes the last session of the run successfully,
both the SWMF.SUCCESS and the SWMF.DONE files are created in the
run directory.
</command>
<command name="CHECKTIMESTEP">
<parameter name="DoCheckTimeStep" type="logical" default="T"/>
<if expr="$DoCheckTimeStep">
<parameter name="DnCheckTimeStep" type="integer" minimum="2" default="10"/>
<parameter name="TimeStepMin" type="real" minimum="-1" default="-1"/>
</if>
#CHECKTIMESTEP
T DoCheckTimeStep (rest is read if true)
10 DnCheckTimeStep (2 or more)
-1.0 TimeStepMin [s] (negative value means SessionTime/10,000,000)
This command is only effective in time accurate mode. The goal is to
avoid a simulation stalling with infinitesimal time steps.
If DoCheckTimeStep is true, then check if the average time advance
over DnCheckTimeStep iterations is smaller than TimeStepMin, and if it is,
stop the simulation with an error message. The check is performed every
nCheckTimeStep iterations on all active processors of the SWMF.
A positive TimeStepMin is the minimum average time advance in units of seconds.
A negative TimeStepMin value is replaced with the simulation time of the
session divided by hundred million, which assumes that a session should be
completed in less than hundred million iterations.
Default values are shown above, so the check is active by default.
</command>
<command name="CHECKKILL">
<parameter name="NameCompCheckKill" type="string" length="2"
default="!!"/>
#CHECKKILL
GM NameCompCheckKill
The SWMF can check periodically if the SWMF.KILL file exists in the run
directory, and kill the execution if it does. This file gets removed
at the beginning of the run so that new runs don't get killed accidentally.
This check is done from the root processor of the
component NameCompCheckKill in the SWMF time loop. This means that
the component doing the check will not get interrupted at an arbitrary
point of execution (e.g. writing output files). The other components
sharing the same processor will also be safe. Components running on
a separate subset of processors may get interrupted at a more-or-less
arbitrary point of execution.
If NameCompCheckKill is set to the string '??' then all processors check
for the SWMF.KILL file. This makes sure that the run gets terminated
essentially immediately. If NameCompCheckKill is set to the string '!!'
then no check is performed at all. Otherwise NameCompCheckKill should
contain the component ID of a component present in the
#COMPONENTMAP command.
If the code gets killed, no SWMF.SUCCESS or SWMF.DONE files are created.
The default value is NameCompCheckKill='!!', i.e. no check is performed.
</command>
<command name="CHECKSTOP">
<parameter name="DoCheckStop" type="logical" default="F" />
<if expr="$DoCheckStop">
<parameter name="DnCheckStop" type="integer" min="-1"
default="-1" />
<parameter name="DtCheckStop" type="real" min="-1"
default="-1" />
</if>
#CHECKSTOP
T DoCheckStop
-1 DnCheckStop
10.0 DtCheckStop
The DoCheckStop variable controls whether CON should
check the CPU time or the existence of the SWMF.STOP file in the
run directory. If it is set to false, there is no checking.
If it is set to true, the stop conditions are checked at the
frequencies given by the DnCheckStop and DtCheckStop variables.
The DnCheckStop variable determines the frequency in terms of
the time step number nStep, while DtCheckStop determines the
frequency in terms of the simulation time tSimulation.
Negative values for either variable mean that the corresponding condition
is not checked. For time accurate mode DtCheckStop, for
steady-state mode DnCheckStop is the relevant frequency.
The default value is DoCheckStop=.false., because the checks require
synchronization of the components. The more frequent the checks
are the less efficient the execution. On the other hand the
less frequent the checks are, the less control the user has to stop
the code at a given time.
If the code is stopped this way for any reason (for example the
CPU time maximum is reached or the SWMF.STOP file was used),
an SWMF.SUCCESS file is created but no SWMF.DONE file is created.
</command>
<command name="CHECKSTOPFILE">
<parameter name="DoCheckStopFile" type="logical" default="T" />
#CHECKSTOPFILE
T DoCheckStopFile
If DoCheckStopFile is true (and DoCheckStop is set
to true in the #CHECKSTOP command) then the code checks if the
SWMF.STOP file exists in the run directory. This file is deleted at
the beginning of the run, so the user must explicitly create the file
with, for example, the "touch SWMF.STOP" UNIX command.
If the file is found in the run directory,
the execution stops in a graceful manner.
Restart files and plot files are saved as required by the
appropriate parameters.
The default is DoCheckStopFile=.true. (but the default for DoCheckStop
is .false.).
</command>
<command name="CPUTIMEMAX">
<parameter name="CpuTimeMax" type="real" min="-1" default="-1" />
#CPUTIMEMAX
7.5 hours CpuTimeMax [sec]
The CpuTimeMax variable contains the maximum allowed CPU time (wall clock
time) for the execution of the current run. If the CPU time reaches
this time, the execution stops in a graceful manner.
Restart files and plot files are saved as required by the
appropriate parameters.
This command is very useful when the code is submitted to a batch
queue with a limited wall clock time.
The default value is -1.0, which means that the CPU time is not checked.
To do the check the CpuTimeMax variable has to be set to a positive
value and the DoCheckStop variable also must be set to .true.
in the #CHECKSTOP command.
</command>
</commandgroup>
<commandgroup name="TESTING AND TIMING">
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!! TESTING AND TIMING !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<command name="TESTINFO">
<parameter name="DoWriteCallSequence" type="logical" default="F"/>
#TESTINFO
T DoWriteCallSequence
If DoWriteCallSequence is set to true, the code will attempt to produce
a call sequence from the CON_stop subroutine (which is called when the
code finds an error) by making an intentional floating point exception.
This will work only if the compiler is able to and requested to produce a
call sequence. The NAGFOR compiler combined with the -debug flag can do that.
Default is DoWriteCallSequence=F.
</command>
<command name="TEST">
<parameter name="StringTest" type="string" length="200"/>
#TEST
do_session StringTest
A space separated list of subroutine and function names to be tested.
Only subroutines containing the 'call CON_set_do_test(...)' statement
can be tested. The first argument is the name of the subroutine,
usually defined as the string parameter 'NameSub'.
Default is an empty string.
</command>
<command name="TESTPROC">
<parameter name="iProcTest" type="integer" min="0" default="0"/>
#TESTPROC
1 iProcTest
The test information will be written from iProcTest when DoTestMe is used
in the SWMF. Default value is 0.
</command>
<command name="VERBOSE">
<parameter name="lVerbose" type="integer" input="select">
<option name="errors and warnings only" value="0" />
<option name="normal" value="1" default="T"/>
<option name="calls on test processor" value="10" />
<option name="calls on all processors" value="100" />
</parameter>
#VERBOSE
100 lVerbose
The lVerbose variable sets the verbosity of CON.\\
If lVerbose=0 the verbose information is minimized.\\
If lVerbose=1 some verbose information is printed in CON_main and CON_io
from processor zero.\\
If lVerbose=10, processor zero will produce a line on the standard output
with the name of the subroutine and the iteration number
for all subroutines which call CON_set_do_test.\\
If lVerbose=100, all processors and all subroutines which call CON_set_do_test
will produce a line on the standard output with the
name of the subroutine, the iteration number and the processor number.\\
The default value is lVerbose=1.
</command>
<command name="TIMING">
<parameter name="UseTiming" type="logical" default="T" />
<if expr="$UseTiming">
<parameter name="DnTiming" type="integer" input="select">
<option name="none" value="-3" />
<option name="final only" value="-2"
default="T" />
<option name="end of sessions" value="-1" />
<optioninput name="every X steps" min="1"
default="100" />
</parameter>
<parameter name="nDepthTiming" type="integer" min="-1"
default="-1" />
<parameter name="TypeTimingReport" type="strings"
min="1" max="2">
<part name="TypeTimingStyle" type="string" required="T"
input="select">
<option name="cumulative" value="cumu"
default="T" />
<option name="list" />
<option name="tree" />
</part>
<part name="UseTimingAll" type="string" required="F"
input="select">
<option name="all" />
</part>
</parameter>
</if>
#TIMING
T UseTiming rest of parameters read if true
-2 DnTiming -3 none, -2 final, -1 each session
-1 nDepthTiming -1 for arbitrary depth
tree all TypeTimingReport 'cumu','list','tree', +optional 'all'
If UseTiming=.true., the execution is timed by the TIMING utility.\\
If UseTiming=.false., the execution is not timed.\\
\noindent
The DnTiming parameter determines the frequency of timing reports:\\
If DnTiming is positive, a timing report is produced every DnTiming steps.\\
If DnTiming is -1, a timing report is shown at the end of each session.\\
If DnTiming is -2, a timing report is shown at the end of the whole run.\\
If DnTiming is -3, no timing report is shown.\\
\noindent
The nDepthTiming parameters defines the depth of the timing tree.\\
A negative value means unlimited depth.\\
If nDepthTiming is 1, only the total SWMF execution is timed.\\
\noindent
The TypeTimingReport parameter determines the format of the timing reports:
\begin{verbatim}
'cumu' - cumulative list sorted by timings
'list' - list based on caller and sorted by timings
'tree' - tree based on calling sequence.
\end{verbatim}
If the word 'all' is added, the timing is done on all the CPU-s.
By default only the root CPUs of the components do timings.
When all the CPU-s are timed, it is probably a good idea to
direct the output into separate files (see the #STDOUT command).
The default values are shown above, except for the
TimingReportStyle, which is 'cumu' by default without the 'all'.
</command>
<command name="PROGRESS">
<parameter name="DnProgressShort" type="integer" min="-1"
default="10" />
<parameter name="DnProgressLong" type="integer" min="-1"
default="100" />
#PROGRESS
10 DnProgressShort
100 DnProgressLong
The DnShowProgressShort and DnShowProgressLong variables determine
the frequency of showing short and long progress reports in terms
of the number of time steps nStep. The short progress report
consists of a single line which shows the number of time steps,
simulation time and CPU time. The long progress report also shows
a small timing report on the root processor.
Negative values indicate that no report is requested.
The default values are DnShowProgressShort=10 and DnShowProgressLong=100.
</command>
<command name="PRECISION" if="$_IsFirstSession">
<parameter name="nByteReal" type="integer" input="select">
<option name="single precision (4)" value="4"
default="$nByteReal==4" />
<option name="double precision (8)" value="8"
default="$nByteReal==8" />
</parameter>
<rule expr="$nByteReal==$_nByteReal or not $UseStrict">
nByteReal in file must agree with _nByteReal in strict mode.
</rule>
#PRECISION
8 nByteReal
The nByteReal variable gives the number of bytes in the default real variable.
Possible values are 4 and 8. This command serves to check consistency with
binary data, such as binary restart files.
The #PRECISION command and the nByteReal variable
are saved into the restart file. If the compiled precision differs from
the one defined by nByteReal, the code stops with an error message
in strict mode. If the strict mode is switched off with the #STRICT
command, only a warning is printed.
There is no default value. If the command is not used, the precision of
the real numbers is not checked.
</command>
<command name="VERSION" if="$_IsFirstSession">
<parameter name="VersionSwmf" min="0" default="1.0" type="real" />
#VERSION
1.0 VersionSwmf
This command is obsolete. We now use Git references to identify the
code version. The only use of this command is to be compatible with
restart files produced before VersionSwmf was removed.
</command>
</commandgroup>
<commandgroup name="COMPONENT CONTROL">
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!! COMPONENT CONTROL !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The session model allows concurrent execution of the components.
The components are synchronized only when conditions for the actions of
coupling, saving restart files, or stopping execution are met.
This is possible because it is known in advance by each component when
these actions will occur. In time accurate mode the components are
required to make a time step which does not exceed the next synchronization
time. In steady state mode there is no limit on the time step, and
components can be called at different frequencies.
Components which are not used in a session can be switched off.
<command name="#COMPONENTMAP" alias="LAYOUT" if="$_IsFirstSession">
<set name="_COMPONENTMAP" type="logical" value="T"/>
<foreach values="$_Components">
<parameter name="CompMap" type="strings" min="1" max="5">
<part name="NameComp" type="string" length="2" required="T"/>
<part name="ProcFirst" type="integer" default="0" required="T"/>
<part name="ProcLast" type="integer" default="$ProcFirst" required="T"/>
<part name="Stride" type="integer" default="1" required="T"/>
<part name="nThread" type="integer" default="$Stride" required="F"/>
</parameter>
</foreach>
ID Proc0 ProcEnd Stride nThread TAB SEPARATED comment
#COMPONENTMAP
IE 0 0 1 CompMap IE runs on PE 0
PW 1 32 4 4 CompMap PW runs on PEs 1..32 with 4 threads
GM 33 -1 16 16 CompMap GM runs on PEs 33... with 16 threads
ID Proc0 ProcEnd Stride nThread TAB SEPARATED comment
#LAYOUT
GM 0 -3 -2 -2 CompMap GM runs on PEs ..nProc-3 with MaxThread/2 threads
PC 0 -3 -1 -1 CompMap PC runs on PEs ..nProc-3 with MaxThread threads
IM -2 -2 1 CompMap IM runs on PE nProc-2
IE -2 -1 1 CompMap IE runs on PEs nProc-2 and nProc-1
This command can only occur in the first session, where it is required.
The #COMPONENTMAP (or #LAYOUT) command lists the active components and
their processor layout including the number of OpenMP threads for
components that can run with OpenMP. To use multithreading, the code
needs to be configured with the -openmp flag. The list of components
should be ended with an empty line.
The columns contain the component ID, the index of the first (root)
processor for the component, the last processor, the stride, and the
optional number of threads, respectively. Negative values for the
root and last processor ranks are taken as counting backwards
from the total number of processors nProc. Negative values for the
stride and number of threads are interpreted as the maximum number of
threads (MaxThread is defined by the OMP_NUM_THREADS environment
variable) divided by the absolute value of Stride or nThread,
respectively. This allows the same layout to be used on different
nodes with different number of cores per node. The default number of
threads is 1 and the maximum value is MaxThread.
This command is required in the first session of the PARAM.in file.
</command>
<command name="COMPONENT" multiple="T">
<parameter name="NameComp" type="string" input="select">
<option name="CZ" />
<option name="EE" />
<option name="GM" default="T"/>
<option name="IE" />
<option name="IH" />
<option name="IM" />
<option name="OH" />
<option name="PC" />
<option name="PS" />
<option name="PT" />
<option name="PW" />
<option name="RB" />
<option name="SC" />
<option name="SP" />
<option name="UA" />
</parameter>
<parameter name="UseComp" type="logical" default="T"/>
<rule expr="$_Registered{$NameComp} or not $_Components">
Component must be registered.
</rule>
<set name="_UsedComp{$NameComp}" type="logical" value="$UseComp"/>
#COMPONENT
IE NameComp
F UseComp
The NameComp variable contains the two-character component ID,
while the UseComp variable defines if the component should be
used in the current session or not. It is possible that in the
initial sessions some components are not used, and they are turned on later.
Unused components should not be coupled, and they should not
be given any parameters.
The default is that all the components listed in the #COMPONENTMAP command
are used.
</command>
<command name="CYCLE" multiple="T">
<parameter name="NameComp" type="string" input="select">
<option name="CZ" />
<option name="EE" />
<option name="GM" default="T"/>
<option name="IE" />
<option name="IH" />
<option name="IM" />
<option name="OH" />
<option name="PC" />
<option name="PS" />
<option name="PT" />
<option name="PW" />
<option name="RB" />
<option name="SC" />
<option name="SP" />
<option name="UA" />
</parameter>
<parameter name="DnRun" type="integer" min="1" default="1"/>
#CYCLE
IH NameComp
10 DnRun
The DnRun variable defines the frequency of calling component NameComp
during a steady state run. In the example IH will be called for
nStep = 10, 20, 30, ... For time accurate runs this command has no effect.
The default is DnRun = 1 for all the active components.
</command>
</commandgroup>
<commandgroup name="COUPLING CONTROL">
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!! COUPLING CONTROL !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<command name="COUPLEORDER">
<parameter name="nCouple" type="integer" min="0" max="38"
default="10"/>
<for from="1" to="$nCouple">
<parameter name="NameSourceTarget" type="string" length="5"/>
</for>
#COUPLEORDER
5 nCouple
IE GM NameSourceTarget
IE IM NameSourceTarget
GM IE NameSourceTarget
GM IM NameSourceTarget
IM GM NameSourceTarget
The nCouple variable determines the maximum number of couplings
among the components. The NameSourceTarget string contains the two
two-character IDs for the source and target components separated by
a space. The order of the couplings is most important for the
couplings done at the beginning of the session. Some components need
to get information from the others before they can initialize properly.
For example IM/RCM2 gets information from GM/BATSRUS.
With respect to coupling between IE and the other components
there are two strategies:
1. All components send information to IE first, then IE solves for
the potential and sends it back to all the other components.
2. IE sends information based on its current state first, then receives info
from the other components, and solves for the potential in parallel with the
other components.
The default coupling order follows the first strategy. In this case
IE runs in a serial mode, so it should share processors with one of the
components that are coupled to IE.
The example shown above follows the second strategy, which leads to
concurrent execution IF the layout puts IE on a processor
that is NOT shared with the slowest of the components
(typically GM, sometimes IM).
To use the second strategy it is simplest to add the
#INCLUDE
Param/CoupleOrderFast
command into the PARAM.in file. The Param/CoupleOrderFast contains the
coupling order that allows concurrent execution of IE.
NOTE: The #COUPLEORDER command defines only the order of the couplings,
so it can list couplings that are not active in a run.
NOTE: The order of the 'SC SP' and 'IH SP' couplings should not be reversed!
The default coupling order is specified by the iCompCoupleOrder_II array
initialized in the \\
CON/Coupler/src/CON_coupler.f90 file.
</command>
<command name="COUPLE1" multiple="T">
<parameter name="NameSource" type="string" length="2" />
<parameter name="NameTarget" type="string" length="2" />
<parameter name="DnCouple" type="integer" min="-1" default="-1" />
<parameter name="DtCouple" type="real" min="-1" default="-1.0" />
<rule expr="$_UsedComp{$NameSource} or not $_Components">
Source component must be registered and ON.
</rule>
<rule expr="$_UsedComp{$NameTarget} or not $_Components">
Target component must be registered and ON.
</rule>
<rule expr="$NameSource ne $NameTarget">
Source and target components must be different.
</rule>
#COUPLE1
IE NameSource
IM NameTarget
-1 DnCouple
10.0 DtCouple
The NameSource and NameTarget variables contain the two-character
component ID-s for the source and target components.
The DnCouple variable determines the frequency
of couplings in terms of the number of time steps nStep for steady state
runs, while DtCouple defines the frequency in terms of the simulation
time tSimulation in seconds for time-accurate runs. Setting both
frequencies to a negative value means that there is no coupling.
The default is no coupling between the components.
</command>
<command name="COUPLE2" multiple="T">
<parameter name="NameComp1" type="string" length="2" />
<parameter name="NameComp2" type="string" length="2" />
<parameter name="DnCouple" type="integer" min="-1" default="-1" />
<parameter name="DtCouple" type="real" min="-1" default="-1.0" />
<rule expr="$_UsedComp{$NameComp1} or not $_Components">
Component 1 must be registered and ON.
</rule>
<rule expr="$_UsedComp{$NameComp2} or not $_Components">
Component 2 must be registered and ON.
</rule>
<rule expr="$NameComp1 ne $NameComp2">
Components 1 and 2 must be different.
</rule>
#COUPLE2
GM NameComp1
IE NameComp2
-1 DnCouple
10.0 DtCouple
The NameComp1 and NameComp2
variables contain the two-character component ID-s for the two
components which are coupled both ways.
The DnCouple variable determines the frequency
of couplings in terms of the number of time steps nStep for steady state runs,
while DtCouple defines the frequency in terms of the simulation
time tSimulation in seconds for time-accurate runs. Setting both
frequencies to a negative value means that there is no coupling.
The default is no coupling between the components.
</command>
<command name="COUPLE1SHIFT" multiple="T">
<parameter name="NameSource" type="string" length="2" />
<parameter name="NameTarget" type="string" length="2" />
<parameter name="DnCouple" type="integer" min="-1" default="-1" />
<parameter name="DtCouple" type="real" min="-1" default="-1.0" />
<parameter name="nNext12" type="integer" min="-1" max="$DnCouple"
default="0.0" />
<parameter name="tNext12" type="real" min="-1" max="$DtCouple"
default="0.0" />
<rule expr="$_UsedComp{$NameSource} or not $_Components">
Source component must be registered and ON.
</rule>
<rule expr="$_UsedComp{$NameTarget} or not $_Components">
Target component must be registered and ON.
</rule>
<rule expr="$NameSource ne $NameTarget">
Source and target components must be different.
</rule>
#COUPLE1SHIFT
IH NameSource
GM NameTarget
-1 DnCouple
10.0 DtCouple
-1 nNext12
3.0 tNext12
The NameSource and NameTarget
variables contain the two-character component ID-s for the source
and target components. The DnCouple variable determines the frequency
of couplings in terms of the number of time steps nStep for steady state
runs, while DtCouple defines the frequency in terms of the simulation
time tSimulation in seconds for time-accurate runs.
For steady-state simulations the nNext12 variable determines in which time
step the first coupling occurs after the initial coupling, namely
when mod(nStep,DnCouple) equals nNext12. For time accurate
simulations the tNext12 variable determines at what simulation
time the first coupling occurs after the initial coupling, namely
when mod(tSimulation,DtCouple) equals tNext12.
The above example will couple IH to GM at simulation times 3, 13, 23, etc.
The default is no shifting.
</command>
<command name="COUPLE2SHIFT" multiple="T">
<parameter name="NameComp1" type="string" length="2" />
<parameter name="NameComp2" type="string" length="2" />
<parameter name="DnCouple" type="integer" min="-1" default="-1" />
<parameter name="DtCouple" type="real" min="-1" default="-1.0" />
<parameter name="nNext12" type="integer" min="-1" max="$DnCouple"
default="0.0" />
<parameter name="tNext12" type="real" min="-1" max="$DtCouple"
default="0.0" />
<parameter name="nNext21" type="integer" min="-1" max="$DnCouple"
default="0.0" />
<parameter name="tNext21" type="real" min="-1" max="$DtCouple"
default="0.0" />
<rule expr="$_UsedComp{$NameComp1} or not $_Components">
Component 1 must be registered and ON.
</rule>
<rule expr="$_UsedComp{$NameComp2} or not $_Components">
Component 2 must be registered and ON.
</rule>
<rule expr="$NameComp1 ne $NameComp2">
Components 1 and 2 must be different.
</rule>
#COUPLE2SHIFT
GM NameComp1
IE NameComp2
-1 DnCouple
10.0 DtCouple
-1 nNext12
3.0 tNext12
-1 nNext21
6.0 tNext21
The NameComp1 and NameComp2
variables contain the two-character component ID-s for the two
components which are coupled both ways.
The DnCouple variable determines the frequency
of couplings in terms of the number of time steps nStep for steady state
runs, while DtCouple defines the frequency in terms of the simulation
time tSimulation in seconds for time-accurate runs.
For steady-state simulations the nNext12 variable determines in which time
step the first coupling occurs from NameComp1 to NameComp2
after the initial coupling, namely
when mod(nStep,DnCouple) equals nNext12. For time accurate
simulations the tNext12 variable determines at what simulation
time the first coupling occurs from NameComp1 to NameComp2
after the initial coupling, namely
when mod(tSimulation,DtCouple) equatls tNext12.
The first coupling step and time for the NameComp2 to NameComp1
coupling is determined by the nNext21 and tNext21 variables
in a similar fashion. This command allows to shift the couplings
relative to each other.
The above example will couple GM to IE at simulation times
3, 13, 23, etc, while IE will be coupled to GM at simulation times
6, 16, 26 etc.
This way IE can solve the potential problem while GM advances by 3 seconds.
That can improve the parallelization and efficiency.
The default is no shifting.
</command>
<command name="COUPLE1TIGHT" multiple="T">
<parameter name="NameMaster" type="string" length="2" />
<parameter name="NameSlave" type="string" length="2" />
<parameter name="DoCouple" type="logical" default="T" />
<rule expr="$_UsedComp{$NameMaster} or not $_Components">
Master component must be registered and ON.
</rule>
<rule expr="$_UsedComp{$NameSlave} or not $_Components">
Slave component must be registered and ON.
</rule>
<rule expr="$NameMaster ne $NameSlave">
Master and slave components must be different.
</rule>
#COUPLE1TIGHT
GM NameMaster
PT NameSlave
T DoCouple