You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: loading environment for the current partition
418
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: executing OS command: modulecmd python show daint-gpu
419
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: executing OS command: modulecmd python load daint-gpu
420
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: loading test's environment
421
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: executing OS command: modulecmd python show cudatoolkit
422
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: executing OS command: modulecmd python load cudatoolkit
423
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: setting up paths
424
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: setting up the job descriptor
425
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: job scheduler backend: local
426
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: setting up performance logging
427
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: entering stage: compile
428
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: copying /users/karakasv/Devel/reframe/tutorial/src to stage directory (/users/karakasv/Devel/reframe/stage/gpu/example7_check/PrgEnv
429
+
-cray)
430
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: symlinking files: []
431
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: Staged sourcepath: /users/karakasv/Devel/reframe/stage/gpu/example7_check/PrgEnv-cray/example_matrix_vector_multiplication_cuda.cu
432
+
[2018-03-01T20:03:13] debug: example7_check on daint:gpu using PrgEnv-cray: executing OS command: nvcc -O3 -I/users/karakasv/Devel/reframe/stage/gpu/example7_check/PrgEnv-cray /users/karakasv/Devel/reframe/s
[2018-03-01T20:03:14] debug: example7_check on daint:gpu using PrgEnv-cray: compilation stdout:
435
+
436
+
[2018-03-01T20:03:14] debug: example7_check on daint:gpu using PrgEnv-cray: compilation stderr:
437
+
nvcc warning : The 'compute_20', 'sm_20', and 'sm_21' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
438
+
439
+
[2018-03-01T20:03:14] debug: example7_check on daint:gpu using PrgEnv-cray: compilation finished
440
+
[2018-03-01T20:03:14] debug: example7_check on daint:gpu using PrgEnv-cray: entering stage: run
441
+
[2018-03-01T20:03:14] debug: example7_check on daint:gpu using PrgEnv-cray: executing OS command: sbatch /users/karakasv/Devel/reframe/stage/gpu/example7_check/PrgEnv-cray/example7_check_daint_gpu_PrgEnv-cray
442
+
.sh
443
+
[2018-03-01T20:03:14] debug: example7_check on daint:gpu using PrgEnv-cray: spawned job (jobid=6224537)
444
+
[2018-03-01T20:03:14] debug: example7_check on daint:gpu using PrgEnv-cray: entering stage: wait
445
+
439
446
440
447
Each line starts with a timestamp, the level of the message (``info``, ``debug`` etc.), the context in which the framework is currently executing (either ``reframe`` or the name of the current test and, finally, the actual message.
441
448
@@ -459,7 +466,7 @@ The default configuration looks as follows:
459
466
'reframe.log' : {
460
467
'level' : 'DEBUG',
461
468
'format' : '[%(asctime)s] %(levelname)s: '
462
-
'%(testcase_name)s: %(message)s',
469
+
'%(check_info)s: %(message)s',
463
470
'append' : False,
464
471
},
465
472
@@ -500,9 +507,9 @@ The configurable properties of a log record handler are the following:
500
507
If ReFrame is not in the context of regression test, ``reframe`` will be printed.
501
508
* ``check_jobid``: Prints the job or process id of the job or process associated with currently executing regression test.
502
509
If a job or process is not yet created, ``-1`` will be printed.
503
-
* ``testcase_name``: Print the name of the test case that is currently executing.
504
-
Test case is essentially a tuple consisting of the test name, the current system and partition and the current programming environment.
505
-
This format string prints out like ``<test-name>@<partition> using <environ>``.
510
+
* ``check_info``: Print live information of the currently executing check.
511
+
By default this field has the form ``<check_name> on <current_partition> using <current_environment>``.
512
+
It can be configured on a per test basis by overriding the :func:`info <reframe.core.pipeline.RegressionTest.info>` method in your regression test.
506
513
507
514
* ``datefmt`` (default: ``'%FT%T'``) The format that will be used for outputting timestamps (i.e., the ``%(asctime)s`` field).
508
515
Acceptable formats must conform to standard library's `time.strftime() <https://docs.python.org/3.6/library/time.html#time.strftime>`__ function.
@@ -513,21 +520,26 @@ The configurable properties of a log record handler are the following:
513
520
If set for a ``filename.log`` handler entry, the resulting log file name will be ``filename_<timestamp>.log``.
514
521
This property is ignored for the standard output/error handlers.
515
522
523
+
.. note::
524
+
.. versionchanged:: 2.10
525
+
The ``testcase_name`` logging attribute was replaced with the ``check_info``, which is now also configurable
526
+
527
+
516
528
Performance Logging
517
529
^^^^^^^^^^^^^^^^^^^
518
530
519
531
ReFrame supports additional logging for performance tests specifically, in order to record historical performance data.
520
532
For each performance test, a log file of the form ``<test-name>.log`` is created under the ReFrame's `log directory <#configuring-reframe-directories>`__ where the test's performance is recorded.
521
-
The default format used for this file is ``'[%(asctime)s] %(testcase_name)s (jobid=%(check_jobid)s): %(message)s'`` and ReFrame always appends to this file.
533
+
The default format used for this file is ``'[%(asctime)s] %(check_info)s (jobid=%(check_jobid)s): %(message)s'`` and ReFrame always appends to this file.
522
534
Currently, it is not possible for users to configure performance logging.
[2018-03-01T20:01:20] reframe 2.10: example7_check on daint:gpu using PrgEnv-pgi (jobid=6224525): value: 49.637615, reference: (50.0, -0.1, 0.1)
541
+
[2018-03-01T20:01:20] reframe 2.10: example7_check on daint:gpu using PrgEnv-cray (jobid=6224523): value: 49.931819, reference: (50.0, -0.1, 0.1)
542
+
[2018-03-01T20:01:21] reframe 2.10: example7_check on daint:gpu using PrgEnv-gnu (jobid=6224524): value: 49.428855, reference: (50.0, -0.1, 0.1)
531
543
532
544
The interpretation of the performance values depends on the individual tests.
533
545
The above output is from the CUDA performance test we presented in the `tutorial <tutorial.html#writing-a-performance-test>`__, so the value refers to the achieved Gflop/s.
@@ -617,3 +629,78 @@ Here is an example output of ReFrame using asynchronous execution policy:
617
629
618
630
The asynchronous execution policy may provide significant overall performance benefits for run-only regression tests.
619
631
For compile-only and normal tests that require a compilation, the execution time will be bound by the total compilation time of the test.
632
+
633
+
634
+
Manipulating modules
635
+
--------------------
636
+
637
+
.. versionadded:: 2.11
638
+
639
+
ReFrame allows you to change the modules loaded by a regression test on-the-fly without having to edit the regression test file.
640
+
This feature is extremely useful when you need to quickly test a newer version of a module, but it also allows you to completely decouple the module names used in your regression tests from the real module names in a system, thus making your test even more portable.
641
+
This is achieved by defining *module mappings*.
642
+
643
+
There are two ways to pass module mappings to ReFrame.
644
+
The first is to use the ``--map-module`` command-line option, which accepts a module mapping.
645
+
For example, the following line maps the module ``test_module`` to the module ``real_module``:
646
+
647
+
.. code-block:: none
648
+
649
+
--map-module='test_module: real_module'
650
+
651
+
In this case, whenever ReFrame is asked to load ``test_module``, it will load ``real_module``.
652
+
Any string without spaces may be accepted in place of ``test_module`` and ``real_module``.
653
+
You can also define multiple module mappings at once by repeating the ``--map-module``.
654
+
If more than one mapping is specified for the same module, then the last mapping will take precedence.
655
+
It is also possible to map a single module to more than one target.
656
+
This can be done by listing the target modules separated by spaces in the order that they should be loaded.
657
+
In the following example, ReFrame will load ``real_module0`` and ``real_module1`` whenever the ``test_module`` is encountered:
The second way of defining mappings is by listing them on a file, which you can then pass to ReFrame through the command-line option ``--module-mappings``.
664
+
Each line on the file corresponds to the definition of a mapping for a single module.
665
+
The syntax of the individual mappings in the file is the same as with the option ``--map-module`` and the same rules apply regarding repeated definitions.
666
+
Text starting with ``#`` is considered a comment and is ignored until the end of line is encountered.
667
+
Empty lines are ignored.
668
+
The following block shows an example of module mapping file:
669
+
670
+
.. code-block:: none
671
+
672
+
module-1: module-1a # an inline comment
673
+
module-2: module-2a module-2b module-2c
674
+
675
+
# This is a full line comment
676
+
module-4: module-4a module-4b
677
+
678
+
If both ``--map-module`` and ``--module-mappings`` are passed, ReFrame will first create a mapping from the definitions on the file and it will then process the definitions passed with the ``--map-module`` options.
679
+
As usual, later definitions will override the former.
680
+
681
+
A final note on module mappings.
682
+
Module mappings can be arbitrarily deep as long as they do not form a cycle.
683
+
In this case, ReFrame will issue an error (denoting the offending cyclic dependency).
684
+
For example, suppose having the following mapping file:
685
+
686
+
.. code-block:: none
687
+
688
+
cudatoolkit: foo
689
+
foo: bar
690
+
bar: foobar
691
+
foobar: cudatoolkit
692
+
693
+
If you now try to run a test that loads the module `cudatoolkit`, the following error will be yielded:
0 commit comments