From: Arnaud Giersch Date: Tue, 12 Oct 2021 19:20:18 +0000 (+0200) Subject: Kill trailing whitespaces in docs. X-Git-Tag: v3.30~329 X-Git-Url: http://bilbo.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/commitdiff_plain/8f58249ee1e3d4fff121c049fc018bf6fa9555a8 Kill trailing whitespaces in docs. --- diff --git a/COPYING b/COPYING index cd8b51441a..de9cf753c9 100644 --- a/COPYING +++ b/COPYING @@ -178,11 +178,11 @@ Copyright: Copyright (C) 1984, 1989-1990, 2000-2015 Free Software Foundation, Inc. Copyright (C) 2003-2021. The SimGrid team. License: GPL-3+ and LGPL-2.1 -Comment: Generated with the Bison processor generator (which is GPL-3+) using SimGrid configuration files (that are LGPL-2.1) +Comment: Generated with the Bison processor generator (which is GPL-3+) using SimGrid configuration files (that are LGPL-2.1) Files: src/include/catch.hpp Copyright: - Copyright (c) 2018 Two Blue Cubes Ltd. + Copyright (c) 2018 Two Blue Cubes Ltd. License: BSL-1.0 Files: src/include/xxhash.hpp diff --git a/README.coding b/README.coding index 7417d89d34..37d3e72bd9 100644 --- a/README.coding +++ b/README.coding @@ -20,7 +20,7 @@ SimGrid4 will follow the these rules: - - filenames are unique in the whole project + - filenames are unique in the whole project (because of a bug in Sonar coverage computation) C++ - fields, methods and variables are in snake_case() @@ -40,7 +40,7 @@ SimGrid4 will follow the these rules: - variables and functions are in snake_case() - typedefs do not hide the pointers, i.e. * must be explicit char* sg_host_get_name(sg_host_t* host); - + This is different from the old convention (described below), that should not be used in S4U and its bindings, nor in the kernel. diff --git a/README.md b/README.md index b37f2f53dd..49369d40ca 100644 --- a/README.md +++ b/README.md @@ -8,9 +8,9 @@ # Welcome to the SimGrid project! -SimGrid is a scientific instrument to study the behavior of +SimGrid is a scientific instrument to study the behavior of large-scale distributed systems such as Grids, Clouds, HPC or P2P -systems. It can be used to evaluate heuristics, prototype applications +systems. It can be used to evaluate heuristics, prototype applications or even assess legacy MPI applications. ## Installation @@ -24,15 +24,15 @@ make install ``` ## More information -[Online documentation](https://simgrid.org/doc/latest/) or +[Online documentation](https://simgrid.org/doc/latest/) or [local version](docs/source). -You can also ask your questions, or simply discuss with other users on +You can also ask your questions, or simply discuss with other users on to the [SimGrid mattermost](https://framateam.org/simgrid/channels/town-square) or on the #simgrid IRC channel of the oftc network. Last, the main development of SimGrid is done on [Framagit](https://framagit.org/simgrid/simgrid/), -but we also maintain a [GitHub mirror](https://github.com/simgrid/simgrid/) and an [Inria GitLab mirror](https://gitlab.inria.fr/simgrid/simgrid), +but we also maintain a [GitHub mirror](https://github.com/simgrid/simgrid/) and an [Inria GitLab mirror](https://gitlab.inria.fr/simgrid/simgrid), Thanks for using our software. Please do great things with it and tell the world about it. Tell us, too, because we love to have positive diff --git a/doc/doxygen/FAQ.doc b/doc/doxygen/FAQ.doc index 674f55dac4..ad1fe528f1 100644 --- a/doc/doxygen/FAQ.doc +++ b/doc/doxygen/FAQ.doc @@ -12,7 +12,7 @@ cannot do with SimGrid, you should read the slides from the SimGrid's website. You may find more up-to-date material on the blog of -Martin Quinson. +Martin Quinson. Another great source of inspiration can be found in the @ref s4u_examples. @@ -81,7 +81,7 @@ several simcalls), you obviously cannot use regular synchronization mechanisms (pthread_mutexes in C or the synchronized keyword in Java). This is because the SimGrid kernel locks all processes and unlock them one after the other when they are supposed to run, until they give the -control back in their simcall. If one of them gets locked by the OS +control back in their simcall. If one of them gets locked by the OS before returning the control to the kernel, that's definitively a deadlock. diff --git a/doc/doxygen/inside.doc b/doc/doxygen/inside.doc index d6eb7d0ac0..5428876f42 100644 --- a/doc/doxygen/inside.doc +++ b/doc/doxygen/inside.doc @@ -49,13 +49,13 @@ things, and get them directly in master. Your commit message should follow the git habits, explained in this blog -post, or in the +post, or in the git styleguide of Atom. - + @subsection uhood_tech_inside_codstand Automatically Enforcing our Coding Standards - + If you plan to commit code to the SimGrid project, you definitely need to install the relevant tool to ensure that your changes follow our coding standards: @@ -135,9 +135,9 @@ Note that the links sometimes broken by git or others. Relaunching which valgrind does not really love). All this is configured with: - cmake -Denable_model-checking=OFF - -Denable_mallocators=OFF - -Denable_compile_optimizations=OFF . + cmake -Denable_model-checking=OFF + -Denable_mallocators=OFF + -Denable_compile_optimizations=OFF . * If you break the logs, you want to define XBT_LOG_MAYDAY at the beginning of log.h. It deactivates the whole logging mechanism, diff --git a/doc/doxygen/inside_cmake.doc b/doc/doxygen/inside_cmake.doc index 393fa8a0b7..f65435214b 100644 --- a/doc/doxygen/inside_cmake.doc +++ b/doc/doxygen/inside_cmake.doc @@ -1,26 +1,26 @@ -/*! +/*! @page inside_cmake Adding source files or examples @tableofcontents -SimGrid uses CMake which is a family of tools designed to build, test, and package software. +SimGrid uses CMake which is a family of tools designed to build, test, and package software. @section inside_cmake_addsrc How to add source files? -If you want to rename, add, or delete source file(s) in the SimGrid distribution, you have to edit the -tools/cmake/DefinePackages.cmake configuration file. Files are organized in sections, then find -the section you are interested in and modify it. +If you want to rename, add, or delete source file(s) in the SimGrid distribution, you have to edit the +tools/cmake/DefinePackages.cmake configuration file. Files are organized in sections, then find +the section you are interested in and modify it. Once you're done, test your changes with ``make distcheck``. @section inside_cmake_examples How to add an example? -The first rule is that the content of examples/ must be interesting to the users. It is expected that the users will -take one of these examples and start editing it to make it fit their needs. So, it should be self-contained, +The first rule is that the content of examples/ must be interesting to the users. It is expected that the users will +take one of these examples and start editing it to make it fit their needs. So, it should be self-contained, informative, and should use only the public APIs. -To ensure that all examples actually work as expected, every example is also used as an integration test (see -@ref inside_tests), but you should still strive to keep the code under examples/ as informative as possible for the +To ensure that all examples actually work as expected, every example is also used as an integration test (see +@ref inside_tests), but you should still strive to keep the code under examples/ as informative as possible for the users. In particular, torture test cases should be placed in teshsuite/, not examples/, so that the users don't stumble upon them by error. @@ -30,12 +30,12 @@ The examples/ directory is organized as follows: - examples/platforms/ only contains platforms descriptions in the XML format (see @ref platform for details) - examples/deprecated/msg/ for examples using the MSG API. Here the naming convention is package-example (e.g., app-masterworker). - examples/deprecated/simdag/ for examples using the SimDag API - - examples/deprecated/java/ for examples using the Java bindings to the MSG API. This directory contains packages (app, async, + - examples/deprecated/java/ for examples using the Java bindings to the MSG API. This directory contains packages (app, async, cloud, ...) which in turn contain individual examples. If your new example fits in an existing package, add it here, - or create a new package otherwise. + or create a new package otherwise. In each of these directories, there is a CMakeLists.txt file that has -to be edited to include the new examples. +to be edited to include the new examples. Once you're done, test your changes with ``make distcheck``. diff --git a/doc/doxygen/inside_release.doc b/doc/doxygen/inside_release.doc index a4296b8f3a..cfc2a358e0 100644 --- a/doc/doxygen/inside_release.doc +++ b/doc/doxygen/inside_release.doc @@ -1,4 +1,4 @@ -/*! +/*! @page inside_release Releasing SimGrid @section inside_release_c Releasing the main library @@ -65,7 +65,7 @@ Please apply the following checklist before releasing. - Rebuild and upload the python package - rm -rf dist/ ; python3 setup.py sdist # Build a source distrib - test that the built distrib recompiles: - rm -rf /tmp/pysimgrid && mkdir /tmp/pysimgrid && cp dist/simgrid-*.tar.gz /tmp/pysimgrid + rm -rf /tmp/pysimgrid && mkdir /tmp/pysimgrid && cp dist/simgrid-*.tar.gz /tmp/pysimgrid (cd /tmp/pysimgrid && tar xfz simgrid*.tar.gz && cd simgrid-*/ && python3 setup.py build) - Upload it to pypi (WARNING: you cannot modify uploaded files, ever) twine upload dist/simgrid-*.tar.gz @@ -85,7 +85,7 @@ Please apply the following checklist before releasing. - gbp import-orig ../simgrid_3.*+dfsg.orig.tar.xz - dch -i "New upstream release" # + copy the NEWS into debian/changelog - git mv debian/libsimgrid3.XX.install debian/libsimgrid3.XY.install - - edit debian/control: s/simgrid3.XX/simgrid3.XY/ + - edit debian/control: s/simgrid3.XX/simgrid3.XY/ - Update the simgrid/package.py for spack: https://gitlab.inria.fr/solverstack/spack-repo - Update the Docker images (after pushing to the git) - cd tools/docker && make stable && make tuto-s4u tuto-smpi tuto-mc @@ -99,13 +99,13 @@ Please apply the following checklist before releasing. Release Target date: https://en.wikipedia.org/wiki/Equinox - Bump release number to 3.X.1 in CMakeLists.txt sonar-project.properties docs/source/conf.py setup.py - Deal with deprecations: - - jed include/xbt/base.h: Introduce the next XBT_ATTRIB_DEPRECATED_v??? macro + - jed include/xbt/base.h: Introduce the next XBT_ATTRIB_DEPRECATED_v??? macro - Kill the one for the current release and remove all code that were mandated by the deprecated functions (both in source and headers). - Do the possible cleanups now that these features are gone. -Release numbering semantic: - - 3.X is a named release. +Release numbering semantic: + - 3.X is a named release. - We have 4 named releases per year (for each equinox and solstice) - The ChangeLog and NEWS are complete and informative - All tests pass on all ci systems (or the workarounds are documented) @@ -114,16 +114,16 @@ Release numbering semantic: - These releases are announced to the users - 3.X.Y where Y is even: dot release of 3.X, prerelease of 3.(X+1) - We provide and store a source .tar.gz and a full jarfile on framagit - - These releases are NOT announced publicly, nor really documented. + - These releases are NOT announced publicly, nor really documented. The idea is to have something close to a rolling release. - External projects can depend on dot releases to loosen their - release process from ours, when 4 release a year is not enough + release process from ours, when 4 release a year is not enough - 3.X.Y where Y is odd: git current status between two releases - No expectations on such versions - Example - 3.22.4: unannounced/loosely documented stable release - 3.22.5: git status somewhere between the release of 3.22.4 and the next one - 3.23: Documented and announced stable release - + */ diff --git a/doc/doxygen/inside_tests.doc b/doc/doxygen/inside_tests.doc index 43617ab625..824e69831b 100644 --- a/doc/doxygen/inside_tests.doc +++ b/doc/doxygen/inside_tests.doc @@ -1,4 +1,4 @@ -/*! +/*! @page inside_tests Testing SimGrid This page will teach you how to run the tests, selecting the ones you @@ -29,7 +29,7 @@ cmake. These tests are run for every commit and the result is publicly available. @verbatim -ctest # Launch all tests +ctest # Launch all tests ctest -R msg # Launch only the tests which name match the string "msg" ctest -j4 # Launch all tests in parallel, at most 4 at the same time ctest --verbose # Display all details on what's going on @@ -70,7 +70,7 @@ integration tests. It is distributed with the SimGrid source file, and even comes with a man page. TESH ensures that the output produced by a command perfectly matches the expected output. This is very precious to ensure that no change modifies the timings computed by the models -without notice. +without notice. To add a new integration test, you thus have 3 things to do: @@ -80,9 +80,9 @@ To add a new integration test, you thus have 3 things to do: examples/ and modify the cmake files as explained on this page: @ref inside_cmake_examples. If you feel like you should write a torture test that is not interesting to the users (because nobody - would sanely write something similar in user code), then put it under + would sanely write something similar in user code), then put it under teshsuite/ somewhere. - + - Write the tesh file, containing the command to run, the provided input (if any, but almost no SimGrid test provide such an input) and the expected output. Check the tesh man page for more @@ -96,14 +96,14 @@ To add a new integration test, you thus have 3 things to do: #XBT_LOG_ISENABLED() macro), or the modification of the log formats to hide the timings when they depend on the host machine.@n The script located in /tools/tesh/generate_tesh can - help you a lot in particular if the output is large (though a smaller output is preferable). + help you a lot in particular if the output is large (though a smaller output is preferable). There are also example tesh files in the /tools/tesh/ directory, that can be useful to understand the tesh syntax. - + - Add your test in the cmake infrastructure. For that, modify the following file: @verbatim /teshsuite//CMakeLists.txt - @endverbatim + @endverbatim Make sure to pick a wise name for your test. It is often useful to check a category of tests together. The only way to do so in ctest is to use the -R argument that specifies a regular expression that @@ -119,13 +119,13 @@ the following (assuming that you use tesh as expected). # option --setenv bindir set the directory containing the binary # --setenv srcdir set the directory containing the source file # --cd set the working directory -ADD_TEST(my-test-name ${CMAKE_BINARY_DIR}/bin/tesh +ADD_TEST(my-test-name ${CMAKE_BINARY_DIR}/bin/tesh --setenv bindir=${CMAKE_BINARY_DIR}/examples/my-test/ --setenv srcdir=${CMAKE_HOME_DIRECTORY}/examples/my-test/ --cd ${CMAKE_HOME_DIRECTORY}/examples/my-test/ ${CMAKE_HOME_DIRECTORY}/examples/deprecated/msg/io/io.tesh ) -@endverbatim +@endverbatim As usual, you must run "make distcheck" after modifying the cmake files, to ensure that you did not forget any files in the distributed archive. @@ -133,13 +133,13 @@ to ensure that you did not forget any files in the distributed archive. @section inside_tests_ci Continuous Integration We use several systems to automatically test SimGrid with a large set -of parameters, across as many platforms as possible. +of parameters, across as many platforms as possible. We use Jenkins on Inria servers as a workhorse: it runs all of our tests for many configurations. It takes a long time to answer, and it often reports issues but when it's green, then you know that SimGrid is very fit! We use AppVeyor -to build and somehow test SimGrid on windows. +to build and somehow test SimGrid on windows. @subsection inside_tests_jenkins Jenkins on the Inria CI servers @@ -162,7 +162,7 @@ We have 2 interesting projects on Jenkins: (on Jenkins) to run the script tools/jenkins/DynamicAnalysis.sh In each case, SimGrid gets built in -/builds/workspace/$PROJECT/build_mode/$CONFIG/label/$SERVER/build +/builds/workspace/$PROJECT/build_mode/$CONFIG/label/$SERVER/build with $PROJECT being for instance "SimGrid", $CONFIG "DEBUG" or "ModelChecker" and $SERVER for instance "simgrid-fedora20-64-clang". @@ -183,7 +183,7 @@ template with the following commands: @verbatim #debian/ubuntu apt-get install gcc g++ gfortran automake cmake libboost-dev openjdk-8-jdk openjdk-8-jre libxslt-dev libxml2-dev libevent-dev libunwind-dev libdw-dev htop git python3 xsltproc libboost-context-dev -#for dynamicanalysis: +#for dynamicanalysis: apt-get install jacoco libjacoco-java libns3-dev pcregrep gcovr ant lua5.3-dev sloccount #fedora @@ -200,7 +200,7 @@ pkg install boost-libs cmake openjdk8 automake libxslt libxml2 libunwind git hto #+ clang-devel from ports #osx -brew install cmake boost libunwind-headers libxslt git python3 +brew install cmake boost libunwind-headers libxslt git python3 @endverbatim @subsection inside_tests_appveyor AppVeyor @@ -233,7 +233,7 @@ SonarQube is an open-source code quality analysis solution. Their nice code scanners are provided as plugin. The one for C++ is not free, but open-source project can use it at no cost. That is what we are doing. -Don't miss the great looking dashboard here: +Don't miss the great looking dashboard here: https://sonarcloud.io/dashboard?id=simgrid_simgrid */ diff --git a/doc/doxygen/module-index.doc b/doc/doxygen/module-index.doc index 096e81d84d..83a56794b6 100644 --- a/doc/doxygen/module-index.doc +++ b/doc/doxygen/module-index.doc @@ -25,7 +25,7 @@ parameter in the command line (see @ref outcomes_vizu for details). /** @defgroup ROUTING_API Routing: Determining the communication paths @brief Organize the platform to determine the links used by each communication -@section routing_basics Basic Concepts +@section routing_basics Basic Concepts The purpose of the simgrid::kernel::routing module is to retrieve the routing path between two points in a time- and space-efficient manner. @@ -34,7 +34,7 @@ the created communication, and the summed latency that these links represent. This operation is clearly on the critical path of most SimGrid simulations. -When defining how the information is routed in the simulated network, +When defining how the information is routed in the simulated network, it is certainly very tempting to use a formalism somehow similar to how it is defined on real network. One would have to define the routing tables of each routers interconnections sub-networks, just @@ -49,7 +49,7 @@ large systems, and allows highly optimized datastructures and algorithms in the simulator. The proposed description mechanism is thus much more convenient and efficient. In addition, it is more expressive than the classical solution based on forwarding tables on -each host and router. +each host and router. The price to pay is that this representation of networks is very specific to SimGrid, so you will have to read further to understand @@ -58,7 +58,7 @@ it, even if you already know how real networks work. The central notion here are @b Networking @b Zones. NetZones represent network areas in which the routing is done in an homogeneous way. Conceptually, netzones generalize from the ideas of local networks -(such as Ethernet switched networks) and Autonomous System. The +(such as Ethernet switched networks) and Autonomous System. The network as a whole is represented as a single hierarchy of netzones, meaning that every netzone is part of another netzone (but the @c NetRoot, which is the top-level netzone). @@ -116,6 +116,3 @@ the feasibility of your idea. Please note that as it is not really intended for public use, this module is only partially documented. */ - - - diff --git a/doc/doxygen/module-sd.doc b/doc/doxygen/module-sd.doc index 90276fac3c..1a82ea312e 100644 --- a/doc/doxygen/module-sd.doc +++ b/doc/doxygen/module-sd.doc @@ -1,11 +1,11 @@ -/** +/** @defgroup SD_API SimDag: Legacy handling of DAG algorithms @brief Programming environment for DAG applications SimDag provides functionalities to simulate parallel task scheduling arranged in DAGs (Direct Acyclic Graphs). Only centralized algorithms can be expressed with SimDag; consider using @ref MSG_API "MSG" for -distributed algorithms). +distributed algorithms). SimDag is the oldest interface in SimGrid, even if it was temporarily removed when the new superfast kernel was added in SimGrid v3.0. It @@ -13,7 +13,7 @@ will certainly be deprecated by future releases of the S4U API, when inter-activity dependencies are added. @{ - + @defgroup SD_host_api Hosts @brief Host management @@ -28,9 +28,8 @@ inter-activity dependencies are added. @defgroup SD_storage_api Storages @brief Storage management - + @defgroup SD_simulation Simulation @brief Functions to create the environment and launch the simulation @} */ - diff --git a/doc/doxygen/module-surf.doc b/doc/doxygen/module-surf.doc index 5bf12a2f0b..5482451464 100644 --- a/doc/doxygen/module-surf.doc +++ b/doc/doxygen/module-surf.doc @@ -1,5 +1,5 @@ /** @addtogroup SURF_API - + @section SURF_doc Surf documentation Surf is composed several components: - @ref SURF_simulation @@ -15,7 +15,7 @@ - @ref SURF_lmm - @ref SURF_callbacks - @ref plugin_energy - + */ @@ -48,8 +48,8 @@ #surf_host_model_init_current_default() (which will give you a CLM03 model), or similar (see @ref SURF_models). - To initialize SURF, call - #surf_host_model_init_current_default() or #surf_host_model_init_ptask_L07() + To initialize SURF, call + #surf_host_model_init_current_default() or #surf_host_model_init_ptask_L07() to create the platform. Then you can access the hosts with the @ref simgrid::s4u::Engine::get_all_hosts. diff --git a/doc/doxygen/module-trace.doc b/doc/doxygen/module-trace.doc index ac1e004544..b0e40e5d31 100644 --- a/doc/doxygen/module-trace.doc +++ b/doc/doxygen/module-trace.doc @@ -7,7 +7,7 @@ - @ref TRACE_user_variables @{ - + @defgroup TRACE_category Tracing categories @brief Functions to declare tracing categories. @@ -16,6 +16,6 @@ @defgroup TRACE_user_variables Tracing user variables @brief Functions to declare and define user variables associated to resources. - + @} */ \ No newline at end of file diff --git a/doc/doxygen/outcomes_vizu.doc b/doc/doxygen/outcomes_vizu.doc index 351a7b2e63..9c101618da 100644 --- a/doc/doxygen/outcomes_vizu.doc +++ b/doc/doxygen/outcomes_vizu.doc @@ -2,7 +2,7 @@ SimGrid comes with an extensive support to trace and register what happens during the simulation, so that it can be either visualized or -statistically analysed after the simulation. +statistically analysed after the simulation. This tracing is widely used to observe and understand the behavior of parallel applications and distributed algorithms. Usually, this is diff --git a/doc/doxygen/platform.doc b/doc/doxygen/platform.doc index f17a30356b..9a88bde196 100644 --- a/doc/doxygen/platform.doc +++ b/doc/doxygen/platform.doc @@ -203,7 +203,7 @@ id | yes | string | Name of the link that is supposed to act is just some doc valuable only at the time of writing. This section describes the storage management under SimGrid ; nowadays it's only usable with MSG. It relies basically on linux-like concepts. - You also may want to have a look to its corresponding section in + You also may want to have a look to its corresponding section in @ref msg_file ; access functions are organized as a POSIX-like interface. @@ -241,7 +241,7 @@ be used. There are 3 different categories for routing models: tedious very quickly, as it is very verbose. Consistent with some manually managed real life routing. 3. @ref pf_routing_model_simple "Simple/fast models": those models offer fast, low memory routing - algorithms. You should consider to use this type of model if + algorithms. You should consider to use this type of model if you can make some assumptions about your network zone. Routing in this case is more or less ignored. @@ -259,7 +259,7 @@ destination for each edge. Routers are naturally an important concept ns-3 since the way routers run the packet routing algorithms is actually simulated. SimGrid's analytical models however simply aggregate the routing time -with the transfer time. +with the transfer time. So why did we incorporate routers in SimGrid? Rebuilding a graph representation only from the route information turns out to be a very difficult task, because @@ -269,7 +269,7 @@ It is important to understand that routers are only used to provide topological information. To express this topological information, a route has to be -defined in order to declare which link is connected to a router. +defined in order to declare which link is connected to a router. @subsubsection pf_routing_model_shortest_path Shortest-path based models @@ -464,7 +464,7 @@ routing model (the path is given relative to SimGrid's source directory): @subsection ps_dec Defining routes -There are currently four different ways to define routes: +There are currently four different ways to define routes: | Name | Description | | ------------------------------------------------- | ----------------------------------------------------------------------------------- | @@ -495,7 +495,7 @@ this is not the case for bypass*Route, as it is more probable that you want to bypass only one default route. For an @ref pf_tag_zoneroute "zoneroute", things are just slightly more complicated, as you have -to give the id of the gateway which is inside the zone you want to access ... +to give the id of the gateway which is inside the zone you want to access ... So it looks like this: @verbatim @@ -534,7 +534,7 @@ host @c dst_host that is within @c dst, you need to: | dst | yes | String | See the @c src attribute | | gw_src | yes | String | The gateway that will be used within the src zone; this can be any @ref pf_tag_host "Host" or @ref pf_router "Router" defined within the src zone. | | gw_dst | yes | String | Same as @c gw_src, but with the dst zone instead. | -| symmetrical | no | YES@|NO (Default: YES) | If this route is symmetric, the opposite route (from dst to src) will also be declared implicitly. | +| symmetrical | no | YES@|NO (Default: YES) | If this route is symmetric, the opposite route (from dst to src) will also be declared implicitly. | #### Example #### @@ -563,14 +563,14 @@ host @c dst_host that is within @c dst, you need to: @endverbatim -@subsubsection pf_tag_route <route> +@subsubsection pf_tag_route <route> -The principle is the same as for +The principle is the same as for @ref pf_tag_zoneroute "ZoneRoute": The route contains a list of links that -provide a path from @c src to @c dst. Here, @c src and @c dst can both be either a -@ref pf_tag_host "host" or @ref pf_router "router". This is mostly useful for the -@ref pf_routing_model_full "Full routing model" as well as for the -@ref pf_routing_model_shortest_path "shortest-paths" based models (as they require +provide a path from @c src to @c dst. Here, @c src and @c dst can both be either a +@ref pf_tag_host "host" or @ref pf_router "router". This is mostly useful for the +@ref pf_routing_model_full "Full routing model" as well as for the +@ref pf_routing_model_shortest_path "shortest-paths" based models (as they require topological information). @@ -596,7 +596,7 @@ A route in the @ref pf_routing_model_shortest_path "Shortest-Path routing model" @endverbatim -@note +@note You must only have one link in your routes when you're using them to provide topological information, as the routes here are simply the edges of the (network-)graph and the employed algorithms need to know which edge connects @@ -757,7 +757,7 @@ to a file, later a host/link/cluster, and finally using trace_connect you say that the file trace must be used by the entity. -#### Example #### +#### Example #### @verbatim @@ -767,8 +767,8 @@ you say that the file trace must be used by the entity. @endverbatim -@note - The order here is important. @c trace_connect must come +@note + The order here is important. @c trace_connect must come after the elements @c trace and @c host, as both the host and the trace definition must be known when @c trace_connect is parsed; the order of @c trace and @c host is arbitrary. @@ -838,7 +838,7 @@ that model the platform on which you run your code. For that, you could use our calibration scripts. This leads to very good fits between the platform, the model and the needs. The g5k.xml example resulted of -such an effort, which also lead to an +such an effort, which also lead to an ongoing attempt to automatically extract the SimGrid platform from the Grid'5000 experimental platform. But it's hard to come up with generic models. Don't take these files @@ -1001,19 +1001,19 @@ characteristics (lookup: time to resolve a route): Each routing model automatically adds a loopback link for each declared host, i.e., a network route from the host to itself, if no such route is declared in the XML -file. This default link has a bandwidth of 498 Mb/s, a latency of 15 microseconds, -and is not shared among network flows. +file. This default link has a bandwidth of 498 Mb/s, a latency of 15 microseconds, +and is not shared among network flows. If you want to specify the characteristics of the loopback link for a given host, you -just have to specify a route from this host to itself with the desired characteristics -in the XML file. This will prevent the routing model to add and use the default +just have to specify a route from this host to itself with the desired characteristics +in the XML file. This will prevent the routing model to add and use the default loopback link. @subsection pf_switch I want to describe a switch but there is no switch tag! Actually we did not include switch tag. But when you're trying to -simulate a switch, assuming -fluid bandwidth models are used (which SimGrid uses by default unless +simulate a switch, assuming +fluid bandwidth models are used (which SimGrid uses by default unless ns-3 or constant network models are activated), the limiting factor is switch backplane bandwidth. So, essentially, at least from the simulation perspective, a switch is similar to a @@ -1029,13 +1029,13 @@ as a normal link. You have several possibilities, as usual when modeling things. If your cabinets are homogeneous and the intercabinet network negligible for your study, you should just create a larger cluster with all hosts at -the same layer. +the same layer. In the rare case where your hosts are not homogeneous between the cabinets, you can create your cluster completely manually. For that, create an As using the Cluster routing, and then use one <cabinet> for each cabinet. This cabinet tag can only be used an -As using the Cluster routing schema, and creating +As using the Cluster routing schema, and creating Be warned that creating a cluster manually from the XML with <cabinet>, <backbone> and friends is rather tedious. The diff --git a/doc/doxygen/uhood_arch.doc b/doc/doxygen/uhood_arch.doc index 7ee3fdecb0..ea0a3eb607 100644 --- a/doc/doxygen/uhood_arch.doc +++ b/doc/doxygen/uhood_arch.doc @@ -4,7 +4,7 @@ This page presents the current code organization, as you will see it if you dig into the src/ directory. But things will change during the current Gran Refactoring leading to SimGrid 4. So take the information on this page with a grain of salt, and don't be afraid if -things are not exactly as documented here. +things are not exactly as documented here. At some point, we at least extend this page to present the overall design that we are currently pursuing for SimGrid 4. diff --git a/doc/doxygen/uhood_switch.doc b/doc/doxygen/uhood_switch.doc index 7b579d4cbd..7cd30d079f 100644 --- a/doc/doxygen/uhood_switch.doc +++ b/doc/doxygen/uhood_switch.doc @@ -109,7 +109,7 @@ simulation kernel. Our futures are based on the C++ Concurrency Technical Specification API, with a few differences: - - The simulation kernel is single-threaded so we do not need + - The simulation kernel is single-threaded so we do not need inter-thread synchronization for our futures. - As the simulation kernel cannot block, `f.wait()` is not meaningful @@ -279,7 +279,7 @@ So a simcall is a way for the actor to push a request to the simulation kernel and yield the control until the request is fulfilled. The performance requirements are very high because the actors usually do an inordinate amount of simcalls during the -simulation. +simulation. As for real syscalls, the basic idea is to write the wanted call and its arguments in a memory area that is specific to the actor, and @@ -676,7 +676,7 @@ public: void notify_one(); void notify_all(); - + }; @endcode @@ -768,7 +768,7 @@ expose asynchronous operations in the simulation kernel to the actors. In addition, we wrote variations of some other C++ standard library classes (`SimulationClock`, `Mutex`, `ConditionVariable`) which work in the simulation: - + * using simulated time; * using simcalls for synchronisation. @@ -931,7 +931,7 @@ auto makeTask(F code, Args... args) @endcode -## Notes +## Notes [^getcompared]: diff --git a/docs/find-missing.ignore b/docs/find-missing.ignore index d65176c10c..1f263180fd 100644 --- a/docs/find-missing.ignore +++ b/docs/find-missing.ignore @@ -1,5 +1,5 @@ This file lists the symbols ignored in the documentation. -It follows the RST syntax but is completely ignored by sphinx. +It follows the RST syntax but is completely ignored by sphinx. It is only used by find-missing, that will not report any definition linked here as missing. # This is a bug in find-missing, as these symbols are actually documented diff --git a/docs/manpages/smpirun.1 b/docs/manpages/smpirun.1 index 9aff8279d5..317da350c7 100644 --- a/docs/manpages/smpirun.1 +++ b/docs/manpages/smpirun.1 @@ -83,7 +83,7 @@ Name of the tracefile \fB\-replay\fR Replay a trace instead of actually executing an application. .TP -\fB\-quiet\fR +\fB\-quiet\fR Reduce output verbosity. This is useful to make tests reproducible. .TP \fB\-version\fR @@ -94,7 +94,7 @@ Displays the git hash of SimGrid. .TP .SH SIMULATION OPTIONS You can change many simulation parameters on command line by passing -\fB--cfg\fR=\fIparameter\fR:\fIvalue\fR after the program name. +\fB--cfg\fR=\fIparameter\fR:\fIvalue\fR after the program name. A full list of the existing parameters and their meaning can be found at https://simgrid.org/doc/latest/Configuring_SimGrid.html @@ -112,7 +112,7 @@ The SimGrid team (simgrid-devel@lists.gforge.inria.fr) Copyright (c) 2014-2021. The SimGrid Team. All rights reserved. This program is free software; you may redistribute it and/or modify -it under the terms of GNU LGPL (v2.1) license. +it under the terms of GNU LGPL (v2.1) license. .SH SEE ALSO .B smpicc\fR(1) .B smpicxx\fR(1) diff --git a/docs/manpages/tesh.pod b/docs/manpages/tesh.pod index 23dfbeb351..799bff8130 100755 --- a/docs/manpages/tesh.pod +++ b/docs/manpages/tesh.pod @@ -141,7 +141,7 @@ Tesh also supports perl default value for undefined variables: $ ${bindir:=/usr/bin}/myprogram -=head2 Not enforcing the expected output +=head2 Not enforcing the expected output By default, the commands output is matched against the one expected, and an error is raised on discrepancy. Metacommands to change this: @@ -193,7 +193,7 @@ This approach may seem surprising at the first glance but it does its job: =over 4 -=item Every timestamps remain separated, as it should; +=item Every timestamps remain separated, as it should; =item In each timestamp, the output order of processes become reproducible: that's the lexicographical order of their name; diff --git a/docs/source/Configuring_SimGrid.rst b/docs/source/Configuring_SimGrid.rst index 936857d455..0c352a52a5 100644 --- a/docs/source/Configuring_SimGrid.rst +++ b/docs/source/Configuring_SimGrid.rst @@ -402,7 +402,7 @@ or more concisely in `this paper `_, even if that paper does only describe models for myrinet and ethernet. You can see in Fig 2 some results for Infiniband, for example. This model may be outdated by now for modern infiniband, anyway, so a new -validation would be good. +validation would be good. The three paramaters are defined as follows: @@ -428,15 +428,15 @@ a simple translation of this text. First, some notations: To determine the penalty for a communication, two values need to be calculated. First, the penalty caused by the conflict in transmission, noted ps. -- if ∆s (i) = 1 then ps = 1. +- if ∆s (i) = 1 then ps = 1. - if ∆s (i) ≥ 2 and ∆e (i) ≥ 3 then ps = ∆s (i) × βs × γr -- else, ps = ∆s (i) × βs +- else, ps = ∆s (i) × βs Then, the penalty caused by the conflict in reception (noted pe) should be computed as follows: - if ∆e (i) = 1 then pe = 1 -- else, pe = Φ (e) × βe × Ω (s, e) +- else, pe = Φ (e) × βe × Ω (s, e) Finally, the penalty associated with the communication is: p = max (ps ∈ s, pe) @@ -467,9 +467,9 @@ Note that with the default host model this option is activated by default. Configuring loopback link ^^^^^^^^^^^^^^^^^^^^^^^^^ -Several network model provide an implicit loopback link to account for local +Several network model provide an implicit loopback link to account for local communication on a host. By default it has a 10GBps bandwidth and a null latency. -This can be changed with ``network/loopback-lat`` and ``network/loopback-bw`` +This can be changed with ``network/loopback-lat`` and ``network/loopback-bw`` items. .. _cfg=smpi/async-small-thresh: @@ -871,7 +871,7 @@ want to reduce the ``contexts/stack-size`` item. Its default value is 8192 (in KiB), while our Chord simulation works with stacks as small as 16 KiB, for example. You can ensure that some actors have a specific size by simply changing the value of this configuration item before -creating these actors. The :cpp:func:`simgrid::s4u::Engine::set_config` +creating these actors. The :cpp:func:`simgrid::s4u::Engine::set_config` functions are handy for that. This *setting is ignored* when using the thread factory (because there @@ -964,7 +964,7 @@ you never used the tracing API. categorization). - MSG or SimDag-based simulator and categorized traces (you need to - declare categories and classify your tasks according to them) + declare categories and classify your tasks according to them) .. code-block:: none @@ -1516,7 +1516,7 @@ of the SMPI CourseWare (see Activity #2.2 of the pointed assignment). In practice, change the calls for malloc() and free() into SMPI_SHARED_MALLOC() and SMPI_SHARED_FREE(). -SMPI provides two algorithms for this feature. The first one, called +SMPI provides two algorithms for this feature. The first one, called ``local``, allocates one block per call to SMPI_SHARED_MALLOC() (each call site gets its own block) ,and this block is shared among all MPI ranks. This is implemented with the shm_* functions @@ -1773,8 +1773,8 @@ As with printf, you can specify the precision and width of the fields. For examp If you want to have spaces in your log format, you should protect it. Otherwise, SimGrid will consider that this is a space-separated list of several parameters. But you should -also protect it from the shell that also splits command line arguments on spaces. At the end, you should use something such as ``--log="'root.fmt:%l: [%p/%c]: %m%n'"``. -Another option is to use the ``%e`` directive for spaces, as in ``--log=root.fmt:%l:%e[%p/%c]:%e%m%n``. +also protect it from the shell that also splits command line arguments on spaces. At the end, you should use something such as ``--log="'root.fmt:%l: [%p/%c]: %m%n'"``. +Another option is to use the ``%e`` directive for spaces, as in ``--log=root.fmt:%l:%e[%p/%c]:%e%m%n``. Category appender ................. diff --git a/docs/source/Deploying_your_application.rst b/docs/source/Deploying_your_application.rst index 2eb5d0fa76..7064655adf 100644 --- a/docs/source/Deploying_your_application.rst +++ b/docs/source/Deploying_your_application.rst @@ -46,7 +46,7 @@ archive for files named ``???_d.xml`` for more): - @@ -62,7 +62,7 @@ archive for files named ``???_d.xml`` for more): -------- -This tag starts a new actor executing the given function on a given host. +This tag starts a new actor executing the given function on a given host. **Parent tags:** :ref:`pf_tag_platform` (only in deployment files) |br| diff --git a/docs/source/Design_goals.rst b/docs/source/Design_goals.rst index cf4ae542d7..956a23d18d 100644 --- a/docs/source/Design_goals.rst +++ b/docs/source/Design_goals.rst @@ -37,7 +37,7 @@ The design of SimGrid is shaped by several design goals: and resource models. But the simulation should be parsimonious too, to not hinder the tool's usability. SimGrid tries to provide sane default settings along with the possibility to augment and modify - the provided models and their default settings. + the provided models and their default settings. - **scalability**: ability to deal with very large simulations. In the number of actors, in the size of the platform, in the number of events, or all together. @@ -120,7 +120,7 @@ the stepwise variation of computational speed depending on the DVFS, and was reused to model the bootup and shutdown phases of a CPU: the computational speed is 0 at these specific pstates. This pstate notion was extended to represent the fact that the bandwidth provided by a -wifi link to a given station depends on its signal-noise ratio (SNR). +wifi link to a given station depends on its signal-noise ratio (SNR). Further on this line, all provided resource models are very comparable internally. They rely on linear inequation systems, stating for diff --git a/docs/source/Experimental_setup.rst b/docs/source/Experimental_setup.rst index d6879aeb5f..d5473bf74a 100644 --- a/docs/source/Experimental_setup.rst +++ b/docs/source/Experimental_setup.rst @@ -23,7 +23,3 @@ Describing the Experimental Setup - Availability and state profiles - Reproducible random number generation - Command line options, in particular on the model switching - - - - diff --git a/docs/source/Installing_SimGrid.rst b/docs/source/Installing_SimGrid.rst index ee8e3de313..0696f9c7b1 100644 --- a/docs/source/Installing_SimGrid.rst +++ b/docs/source/Installing_SimGrid.rst @@ -59,7 +59,7 @@ Nightly built Java Package ^^^^^^^^^^^^^^^^^^^^^^^^^^ Head to the corresponding `GitHub Action `_ -and pick the last green build. At the bottom of the build page, click on the ``jar-final`` artefact. +and pick the last green build. At the bottom of the build page, click on the ``jar-final`` artefact. Open this zip file to find the jar you need. This jar can be used under Linux, Mac OSX or Windows, as you wish. Binary Java Troubleshooting @@ -167,7 +167,7 @@ dependencies. $ make install .. _install_src_config: - + Build Configuration ^^^^^^^^^^^^^^^^^^^ @@ -186,7 +186,7 @@ cmake itself. files, such as ``CMakeCache.txt``. Since Cmake also generates some files in the tree, you may need to wipe out your complete tree and start with a fresh one when you install new dependencies. - + Another (better) solution is to :ref:`build out of the source tree `. @@ -452,15 +452,15 @@ Python-specific instructions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Once you have the Python development headers installed as well as a -recent version of the `pybind11 ` +recent version of the `pybind11 ` module (version at least 2.4), recompiling the Python bindings from -the source should be as easy as: +the source should be as easy as: .. code-block:: console # cd simgrid-source-tree $ python setup.py build install - + Starting with SimGrid 3.13, it should even be possible to install simgrid without downloading the source with pip: @@ -533,4 +533,3 @@ If needed, implement ``i686-linux-gnu-gfortran`` as a script: #!/usr/bin/env sh exec gfortran -m32 "$@" - diff --git a/docs/source/Introduction.rst b/docs/source/Introduction.rst index 7eb452e816..b99d1fea8e 100644 --- a/docs/source/Introduction.rst +++ b/docs/source/Introduction.rst @@ -60,7 +60,7 @@ Here are some questions on which SimGrid is particularly relevant: - **Design the best [Simulated] Platform for a given Application.** Tweaking the platform file is much easier than building a new real - platform for testing purposes. SimGrid also allows for the co-design + platform for testing purposes. SimGrid also allows for the co-design of the platform and the application by modifying both of them. - **Debug Real Applications**. With real systems, is sometimes @@ -107,7 +107,7 @@ explored. In some sense, this mode tests your application for all possible platforms that you could imagine (and more). You just provide the application and its deployment (number of -processes and parameters), and the model checker will +processes and parameters), and the model checker will explore all possible outcomes by testing all possible message interleavings: if at some point a given process can either receive the message A first or the message B depending on the platform @@ -240,4 +240,3 @@ key-value pair storage library developed at the University of Zurich). Some of these applications enjoy large user communities themselves. .. LocalWords: SimGrid - diff --git a/docs/source/Models.rst b/docs/source/Models.rst index 41148c7e84..f0c6b52780 100644 --- a/docs/source/Models.rst +++ b/docs/source/Models.rst @@ -164,7 +164,7 @@ example of an invalid platform: - + @@ -174,7 +174,7 @@ example of an invalid platform: - + This can be reformulated as follows to make it usable with the ns-3 binding. There is no direct connection from alice to bob, but that's OK because ns-3 automatically routes from point to point (using @@ -195,11 +195,11 @@ automatically routes from point to point (using - + - + - + @@ -220,13 +220,13 @@ to see which ones are used in our regression tests. WiFi platforms ^^^^^^^^^^^^^^ -In SimGrid, WiFi networks are modeled with WiFi zones, where a zone contains -the access point of the WiFi network and the hosts connected to it (called -station in the WiFi world). Links inside WiFi zones are modeled as regular -links with a specific attribute, and these links are then added to routes -between hosts. The main difference When using ns-3 WiFi networks is that -the network performance is not given by the link bandwidth and latency but -by the access point WiFi characteristics, and the distance between the access +In SimGrid, WiFi networks are modeled with WiFi zones, where a zone contains +the access point of the WiFi network and the hosts connected to it (called +station in the WiFi world). Links inside WiFi zones are modeled as regular +links with a specific attribute, and these links are then added to routes +between hosts. The main difference When using ns-3 WiFi networks is that +the network performance is not given by the link bandwidth and latency but +by the access point WiFi characteristics, and the distance between the access point and the hosts. So, to declare a new WiFi network, simply declare a zone with the ``WIFI`` @@ -243,14 +243,14 @@ of the WiFi network. -Afterward simply declare the hosts and routers inside the WiFi network. Remember +Afterward simply declare the hosts and routers inside the WiFi network. Remember that one must have the same name as declared in the property "access point". .. code-block:: xml - + Finally, close the WiFi zone. @@ -258,7 +258,7 @@ Finally, close the WiFi zone. -The WiFi zone may be connected to another zone using a traditional link and +The WiFi zone may be connected to another zone using a traditional link and a zoneRoute. Note that the connection between two zones is always wired. .. code-block:: xml @@ -279,7 +279,7 @@ to hosts connected to the wifi zone: Roughly speaking, it defines the speed at which the access point is exchanging data with all stations. It depends on its model and configuration, and the possible values are listed for example on Wikipedia. - |br| By default, ``mcs=3``. + |br| By default, ``mcs=3``. It is a property of the WiFi zone. * ``nss`` (Number of Spatial Streams, or `number of antennas `_) defines the amount of simultaneous data streams that the AP can sustain. @@ -313,7 +313,7 @@ Here is an example of a host changing ``wifi_distance`` value. Random Number Generator ----------------------- -It is possible to define a fixed or random seed to the ns3 random number +It is possible to define a fixed or random seed to the ns3 random number generator using the config tag. .. code-block:: xml @@ -322,14 +322,14 @@ generator using the config tag. - + - ... + ... The first property defines that this platform will be used with the ns3 model. -The second property defines the seed that will be used. Defined to ``time`` -it will use a random seed, defined to a number it will use this number as +The second property defines the seed that will be used. Defined to ``time`` +it will use a random seed, defined to a number it will use this number as the seed. Limitations @@ -343,7 +343,7 @@ platform. However, there are some known caveats: * End hosts cannot have more than one interface card. So, your SimGrid hosts should be connected to the platform through only one link. Otherwise, your SimGrid host will be considered as a router (FIXME: is it still true?). - + Our goal is to keep the ns-3 plugin of SimGrid as easy (and hopefully readable) as possible. If the current state does not fit your needs, you should modify this plugin, and/or create your own plugin from the existing one. If you come up diff --git a/docs/source/Outcomes.rst b/docs/source/Outcomes.rst index 3ecd2a1c2a..9f4af11cfd 100644 --- a/docs/source/Outcomes.rst +++ b/docs/source/Outcomes.rst @@ -13,7 +13,7 @@ should use SimGrid's logging facilities, that are inspired from `Log4J ` are documented online, but some of them may be disabled depending on the compilation options. Use ``--help-log-categories`` on the command line to see +` are documented online, but some of them may be disabled depending on the compilation options. Use ``--help-log-categories`` on the command line to see the categories actually provided a given simulator. The message **priority** represents its severity. It can be one of ``trace``, ``debug``, ``verb``, ``info``, ``warn``, ``error`` and ``critical``. Every category has a configured @@ -37,11 +37,10 @@ change the settings at runtime. Graphical and statistical logging ********************************* -To be written. For now, see `this page `_. +To be written. For now, see `this page `_. Building your own logging ************************* You can add callbacks to the existing signals to get informed of each and every even occurring in the simulator. These callbacks can be used to write logs on disk in the format that you want. Some users did so to visualize the behavior of their simulators with `Jaeger `_. - diff --git a/docs/source/Platform.rst b/docs/source/Platform.rst index 836e48ad27..01fd90b856 100644 --- a/docs/source/Platform.rst +++ b/docs/source/Platform.rst @@ -20,12 +20,12 @@ some drawbacks, but using a specific format ensures that the platform is not mixed with the tested application. This separation of concern :ref:`is a must ` for your Modeling and Simulation (M&S) work. When XML is too limiting, you may describe your platforms using -directly :ref:`C++ code ` +directly :ref:`C++ code ` Any simulated platform must contain **basic elements**, such as :ref:`pf_tag_host`, :ref:`pf_tag_link`, :ref:`pf_tag_disk`, and similar. SimGrid makes no assumption about the **routing of your platform**, so you must declare -explicitly the network path taken between each pair of hosts. +explicitly the network path taken between each pair of hosts. This can be done through a flat list of :ref:`pf_tag_route` for each pair of hosts (routes are symmetrical by default), or you may use the advanced concept of :ref:`networking zone ` to efficiently express the routing of your platform. diff --git a/docs/source/Platform_cpp.rst b/docs/source/Platform_cpp.rst index a7b8e9314c..75abec5785 100644 --- a/docs/source/Platform_cpp.rst +++ b/docs/source/Platform_cpp.rst @@ -11,7 +11,7 @@
.. _platform_cpp: - + C++ Platforms ############# @@ -72,7 +72,7 @@ a split-duplex link. Otherwise, SimGrid cannot know which link (UP/DOWN) to use. .. code-block:: cpp auto* link = zone->create_split_duplex_link("1", "125MBps")->set_latency("24us")->seal(); - + zone->add_route(S1, C1, nullptr, nullptr, {{link, LinkInRoute::Direction::UP}}); .. note:: @@ -91,7 +91,7 @@ function, having a predefined function implemented. When loading the platform, t Engine will look for a function with this signature: "**void load_platform(const sg4::Engine& e)**", and execute it. It could be an easy way to make the transition between XML and C++ if necessary. -For more details, please refer to the cpp and CMakeLists.txt files in +For more details, please refer to the cpp and CMakeLists.txt files in `examples/platform `_. @@ -180,4 +180,3 @@ Note that the leaves and loopback links are defined through callbacks, as follow The code is straightforward and can be easily adapted to more complex environments thanks to the flexibility provided by the C++ API. - diff --git a/docs/source/Platform_examples.rst b/docs/source/Platform_examples.rst index 1e2e971680..b9f8e1d280 100644 --- a/docs/source/Platform_examples.rst +++ b/docs/source/Platform_examples.rst @@ -11,7 +11,7 @@
.. _platform_examples: - + Network Topology Examples ========================= @@ -32,12 +32,12 @@ simulated platform as a graph of hosts and network links. The elements basic elements (with :ref:`pf_tag_host` and :ref:`pf_tag_link`) are described first, and then the routes between -any pair of hosts are explicitly given with :ref:`pf_tag_route`. +any pair of hosts are explicitly given with :ref:`pf_tag_route`. Any host must be given a computational speed in flops while links must be given a latency and a bandwidth. You can write 1Gf for -1,000,000,000 flops (full list of units in the reference guide of -:ref:`pf_tag_host` and :ref:`pf_tag_link`). +1,000,000,000 flops (full list of units in the reference guide of +:ref:`pf_tag_host` and :ref:`pf_tag_link`). Routes defined with :ref:`pf_tag_route` are symmetrical by default, meaning that the list of traversed links from A to B is the same as @@ -241,4 +241,3 @@ The following code illustrates how to create this Star Zone and add the appropri SimGrid comes with an extensive set of platforms in the `examples/platforms `_ directory that should be described here. - diff --git a/docs/source/Platform_howtos.rst b/docs/source/Platform_howtos.rst index 0bf8ac9ae6..6b1d32548f 100644 --- a/docs/source/Platform_howtos.rst +++ b/docs/source/Platform_howtos.rst @@ -124,13 +124,13 @@ timed events with the form "date value". Example: - At time t = 1, the host is turned off (a zero value means OFF) - At time t = 2, the host is turned back on (any other value than zero means ON) - - At time t = 10, the profile is reset (as we are 8 seconds after the last event). Then the host will be turned off + - At time t = 10, the profile is reset (as we are 8 seconds after the last event). Then the host will be turned off again at time t = 11. If your profile does not contain any LOOPAFTER line, then it will be executed only once and not in a repetitive way. Another possibility is to use the -:cpp:func:`simgrid::s4u::Host::set_state_profile()` or +:cpp:func:`simgrid::s4u::Host::set_state_profile()` or :cpp:func:`simgrid::s4u::Link::set_state_profile()` functions. These functions take a profile, that can be a fixed profile exhaustively listing the events, or something else if you wish. @@ -168,7 +168,7 @@ The default model does not account for task pinning, where you manually select on which core each of the existing activity should execute. The best solution to model this is probably to model your 4-core processor as 4 distinct hosts, and assigning the activities to -cores by migrating them to the declared hosts. In some sense, this +cores by migrating them to the declared hosts. In some sense, this takes the whole Network-On-Chip idea really seriously. Some extra complications may arise here. If you have more activities than @@ -231,7 +231,7 @@ Of course, this is only one possible way to model these things. YMMV ;) Modeling parallel links *********************** -Most HPC topologies, such as fat-trees, allow parallel links (a +Most HPC topologies, such as fat-trees, allow parallel links (a router A and a router B can be connected by more than one link). You might be tempted to model this configuration as follows : @@ -250,23 +250,23 @@ You might be tempted to model this configuration as follows : -But that will not work, since SimGrid doesn't allow several routes for +But that will not work, since SimGrid doesn't allow several routes for a single `{src ; dst}` pair. Instead, what you should do is : - Use a single route with both links (so both will be traversed each time a message is exchanged between router A and B) - Double the bandwidth of one link, to model the total bandwidth of - both links used in parallel. This will make sure no combined - communications between router A and B use more than the bandwidth + both links used in parallel. This will make sure no combined + communications between router A and B use more than the bandwidth of two links - - Assign the other link a `FATPIPE` sharing policy, which will allow + - Assign the other link a `FATPIPE` sharing policy, which will allow several communications to use the full bandwidth of this link without having to share it. This will model the fact that individual communications can use at most this link's bandwidth - - Set the latency of one of the links to 0, so that latency is only + - Set the latency of one of the links to 0, so that latency is only accounted for once (since both link are traversed by each message) So the final platform for our example becomes : diff --git a/docs/source/Platform_routing.rst b/docs/source/Platform_routing.rst index 6a25bfd80f..0eaffd428f 100644 --- a/docs/source/Platform_routing.rst +++ b/docs/source/Platform_routing.rst @@ -44,7 +44,7 @@ allows you to have more than one routing model in your platform. For example, you can have a coordinate-based routing for the WAN parts of your platforms, a full routing within each datacenter, and a highly optimized routing within each cluster of the datacenter. In this -case, determining the route between two given hosts gets +case, determining the route between two given hosts gets "somewhat more complex" but SimGrid still computes these routes for you in a time- and space-efficient manner. @@ -182,7 +182,7 @@ through the ``routing=`` parameter. - **Vivaldi/Wi-Fi**: "fully-connected" zones with special characteristics. .. _inter_zone: - + Inter-zone communications ========================= diff --git a/docs/source/Plugins.rst b/docs/source/Plugins.rst index 1ef1475df9..154417cc7a 100644 --- a/docs/source/Plugins.rst +++ b/docs/source/Plugins.rst @@ -33,9 +33,9 @@ Defining a Plugin A plugin can get some additional code executed within the SimGrid kernel, and attach the data needed by that code to the SimGrid -objects. +objects. -The host load plugin in +The host load plugin in `src/plugins/host_load.cpp `_ constitutes a good introductory example. It defines a class ``HostLoad`` that is meant to be attached to each host. This class @@ -55,7 +55,7 @@ kind of objects, please let us now. .. cpp:class:: template simgrid::xbt::signal - A signal/slot mechanism, where you can attach callbacks to a given signal, and then fire the signal. + A signal/slot mechanism, where you can attach callbacks to a given signal, and then fire the signal. The template parameter is the function signature of the signal (the return value currently ignored). diff --git a/docs/source/Release_Notes.rst b/docs/source/Release_Notes.rst index 494f361769..3fedeaaed0 100644 --- a/docs/source/Release_Notes.rst +++ b/docs/source/Release_Notes.rst @@ -28,8 +28,8 @@ The Half Release, a.k.a. the Zealous Easter Trim: Version 3.14 (Dec 25. 2016) --------------------------- -This version (aka, the Christmas Pi) mainly introduces internal reorganization on the way to the future SimGrid 4 version. -These changes should be transparent to the users of the MSG, SMPI and SimDag interfaces, even if some buggy features were reworked +This version (aka, the Christmas Pi) mainly introduces internal reorganization on the way to the future SimGrid 4 version. +These changes should be transparent to the users of the MSG, SMPI and SimDag interfaces, even if some buggy features were reworked while some new features were added. Users are expected to switch to this new version at their own pace, as we do not have the manpower to do any bugfixing on the old releases. @@ -81,7 +81,7 @@ SMPI performance was further improved, using various OS-level magic to speed up Tom to run a simulation of HPL involving 10^6 processes... Wow. The dlopen privatization schema should even allows to run your ranks in parallel (even if it's not well tested yet). -On the Cloud side, we implemented multi-core VMs, which naturally acts as containers of processes; +On the Cloud side, we implemented multi-core VMs, which naturally acts as containers of processes; S4U, the future interface of SimGrid 4.0 also progressed quite a bit. The Storage is currently cleaned up by Fred, and some API changes are to be expected. We are sorry but the exisiting API is so crappy that @@ -125,7 +125,7 @@ This version is dubbed the "The Drained Leaks release", because almost no known Version 3.18 (Dec. 24 2017) --------------------------- -This is an important version for SimGrid: MSG is now deprecated, and new projects should use S4U instead. +This is an important version for SimGrid: MSG is now deprecated, and new projects should use S4U instead. There is still some work to do before SimGrid 4: S4U is not ready for SimDag users yet unfortunately. This will come for sure. Main changes in the "Ho Ho Ho! SimGrid 4 beta is coming to town" release: @@ -133,7 +133,7 @@ Main changes in the "Ho Ho Ho! SimGrid 4 beta is coming to town" release: * Convert almost all interesting MSG examples to S4U. * New model: energy consumption due to the network. * Major cleanups in the disk and storage subsystems. - * (+ further deprecate XBT, bug fixes and doc improvement) + * (+ further deprecate XBT, bug fixes and doc improvement) SimGrid 4 *may* be there by the next solstice. @@ -150,7 +150,7 @@ In total, this "Moscovitly-cold Spring" release brings more than 500 commits mad Version 3.19.1 (March 22. 2018) ------------------------------- -As you may know, we are currently refactoring SimGrid in deep. +As you may know, we are currently refactoring SimGrid in deep. Upcoming SimGrid4 will be really different from SimGrid3: modular, standard and extensible vs. layered, homegrown and rigid. C++ vs. C. Our goal is to smooth this transition, with backward compatibility and automatic update paths, while still progressing toward SimGrid4. @@ -243,7 +243,7 @@ quite a bit of them, but many dark snakes remain in that lake. Fred and Martin c is not finished, but it's not worse than the old one either) while Augustin completed the tutorial for MPI applications. Augustin also added several non-blocking collectives to SMPI, even if Martin finally decided to release right before he could complete the last ones (sorry). We continued cutting on XBT, replacing many functions and modules by their standard counterparts in C++11 or in Boost. We are -now using Catch2 for our unit testing. These cleanups may speedup your simulations by something like 10%. +now using Catch2 for our unit testing. These cleanups may speedup your simulations by something like 10%. Version 3.23 (June 25. 2019) ---------------------------- @@ -327,7 +327,7 @@ This is the "Release" release. Indeed a small contribution to the event, but thi Version 3.27 (March 29. 2021) ----------------------------- -To celebrate the 1176th anniversary of the siege of Paris by Vikings in 845, we just released another version of SimGrid, the Ragnar Release. +To celebrate the 1176th anniversary of the siege of Paris by Vikings in 845, we just released another version of SimGrid, the Ragnar Release. Yeah, that's a stupid release name, but we already had 4 "spring release" in the past, so we needed another name. * SMPI: can now report leaks and hint about the mallocs and kernels hindering simulation scalability @@ -349,7 +349,7 @@ XML. There is a real possibility that this one will be part of the 3.28 release, And the third front is about modernizing the model checker implementation. The current state is very difficult to work with, and we hope that once it's simplified, we will be able to implement more efficient state space reduction techniques, and also allow more synchronization mechanism to be used in the -model checker (for now, our dpor algorithm cannot cope with mutexes). +model checker (for now, our dpor algorithm cannot cope with mutexes). In parallel to these refactoring, the work on SMPI stability and robustness peacefully continued. The list of MPI applications that can now work with absolutely no change on top of SMPI really gets impressive... Check it yourself: https://framagit.org/simgrid/SMPI-proxy-apps @@ -368,7 +368,7 @@ To celebrate the birthday of Crown Princess Victoria, we just released another v * SMPI: improve error handling for incorrect advanced usages. * Many internal cleanups and refactoring to prepare the future. -As usual, even the full changelog is only the tip of the iceberg, given the amount of changes in the backstage. +As usual, even the full changelog is only the tip of the iceberg, given the amount of changes in the backstage. This release is the big one for the programmatic platform descriptions, that are now fully usable from C++. XML will not disappear anytime soon, but it is unlikely that we continue developing it in the future. When starting a new project, you should @@ -394,7 +394,7 @@ Version 3.29 (October 7. 2021) ------------------------------ To celebrate the "Ask a stupid question" release, we wish that every user ask one question about SimGrid. -On `Mattermost `_, +On `Mattermost `_, `Stack Overflow `_, or using the `issues tracker `_. diff --git a/docs/source/The_XBT_toolbox.rst b/docs/source/The_XBT_toolbox.rst index e89aa0d914..b7ec2f717c 100644 --- a/docs/source/The_XBT_toolbox.rst +++ b/docs/source/The_XBT_toolbox.rst @@ -44,7 +44,7 @@ Refer to the :ref:`logging_categories` section for a list of all existing catego .. c:macro:: XBT_LOG_EXTERNAL_CATEGORY(category) - Make an external category (i.e., a category declared in another source file) visible from this source file. + Make an external category (i.e., a category declared in another source file) visible from this source file. In each source file, at most one one category can be the default one. .. c:macro:: XBT_LOG_EXTERNAL_DEFAULT_CATEGORY(category) @@ -190,11 +190,11 @@ Dynamic arrays ************** As SimGrid used to be written in pure C, it used to rely on custom data containers such as dynamic arrays and dictionnaries. Nowadays, the standard library of -C++ is used internally, but some part of the interface still rely on the old containers, that are thus still available. +C++ is used internally, but some part of the interface still rely on the old containers, that are thus still available. -.. warning:: +.. warning:: - You should probably not start a new project using these data structures, as we will :ref:`deprecate them from SimGrid ` + You should probably not start a new project using these data structures, as we will :ref:`deprecate them from SimGrid ` as soon as possible. Better implementations exist out there anyway, in particular if you're not writting pure C code. .. doxygentypedef:: xbt_dynar_t @@ -210,7 +210,7 @@ Creation and destruction Dynars as regular arrays ======================== - + .. doxygenfunction:: xbt_dynar_get_cpy .. doxygenfunction:: xbt_dynar_insert_at .. doxygenfunction:: xbt_dynar_remove_at @@ -223,7 +223,7 @@ Dynar size .. doxygenfunction:: xbt_dynar_is_empty .. doxygenfunction:: xbt_dynar_length .. doxygenfunction:: xbt_dynar_reset - + Perl-like interface =================== @@ -314,7 +314,7 @@ Example with pointed values xbt_dynar_t d = xbt_dynar_new(sizeof(char*), &xbt_free_ref); - /// Push/shift example + /// Push/shift example for (int i = 0; i < NB_ELEM; i++) { char * val = xbt_strdup("hello"); xbt_dynar_push(d, &val); diff --git a/docs/source/Tutorial_Algorithms.rst b/docs/source/Tutorial_Algorithms.rst index 2f4b2023b6..3ccdde3c97 100644 --- a/docs/source/Tutorial_Algorithms.rst +++ b/docs/source/Tutorial_Algorithms.rst @@ -93,7 +93,7 @@ host on which a worker is waiting for something to compute. Then, the tasks are sent one after the other, each on a mailbox named after the worker's hosts. On the other side, a given worker (which -code is given below) waits for incoming tasks on its +code is given below) waits for incoming tasks on its mailbox. @@ -344,7 +344,7 @@ recompile it when you first log in: Using your Computer Natively ............................ -To take the tutorial on your machine, you first need to :ref:`install +To take the tutorial on your machine, you first need to :ref:`install a recent version of SimGrid `, a C++ compiler, and also ``pajeng`` to visualize the traces. You may want to install `Vite `_ to get a first glance at the traces. @@ -459,7 +459,7 @@ using the worker location (which should be filled in two locations), we could use their ID (which should be filled in one location only). -This could be done with the following deployment file. It's +This could be done with the following deployment file. It's not shorter than the previous one, but it's still simpler because the information is only written once. It thus follows the `DRY `_ `SPOT @@ -494,7 +494,7 @@ Wrap up The mailboxes are a very powerful mechanism in SimGrid, allowing many interesting application settings. They may feel unusual if you are used to BSD sockets or other classical systems, but you will soon -appreciate their power. They are only used to match +appreciate their power. They are only used to match communications but have no impact on the communication timing. ``put()`` and ``get()`` are matched regardless of their initiators' location and then the real communication occurs between diff --git a/docs/source/Tutorial_MPI_Applications.rst b/docs/source/Tutorial_MPI_Applications.rst index 310389d561..a2638d2293 100644 --- a/docs/source/Tutorial_MPI_Applications.rst +++ b/docs/source/Tutorial_MPI_Applications.rst @@ -95,12 +95,12 @@ simulated platform as a graph of hosts and network links. The elements basic elements (with :ref:`pf_tag_host` and :ref:`pf_tag_link`) are described first, and then the routes between -any pair of hosts are explicitly given with :ref:`pf_tag_route`. +any pair of hosts are explicitly given with :ref:`pf_tag_route`. Any host must be given a computational speed in flops while links must be given a latency and a bandwidth. You can write 1Gf for -1,000,000,000 flops (full list of units in the reference guide of -:ref:`pf_tag_host` and :ref:`pf_tag_link`). +1,000,000,000 flops (full list of units in the reference guide of +:ref:`pf_tag_host` and :ref:`pf_tag_link`). Routes defined with :ref:`pf_tag_route` are symmetrical by default, meaning that the list of traversed links from A to B is the same as @@ -200,7 +200,7 @@ Here is the meaning of this example: ``2 ; 4,4 ; 1,2 ; 1,2`` - Hosts are connected to only 1 router above them, while these routers are connected to 2 routers above them (thus the ``1,2`` used as ``#uplink``). -- Hosts have only one link to their router while every path between +- Hosts have only one link to their router while every path between level-1 routers and level-2 routers uses 2 parallel links. Thus the ``1,2`` used as ``link count``. @@ -546,18 +546,18 @@ The computing part of this example is the matrix multiplication routine $ smpicxx -O3 gemm_mpi.cpp -o gemm $ time smpirun -np 16 -platform cluster_crossbar.xml -hostfile cluster_hostfile --cfg=smpi/display-timing:yes --cfg=smpi/running-power:1000000000 ./gemm -This should end quite quickly, as the size of each matrix is only 1000x1000. +This should end quite quickly, as the size of each matrix is only 1000x1000. But what happens if we want to simulate larger runs? Replace the size by 2000, 3000, and try again. The simulation time increases a lot, while there are no more MPI calls performed, only computation. -The ``--cfg=smpi/display-timing`` option gives more details about execution +The ``--cfg=smpi/display-timing`` option gives more details about execution and advises using sampling if the time spent in computing loops seems too high. -The ``--cfg=smpi/host-speed:1000000000`` option sets the speed of the processor used for -running the simulation. Here we say that its speed is the same as one of the -processors we are simulating (1Gf), so that 1 second of computation is injected +The ``--cfg=smpi/host-speed:1000000000`` option sets the speed of the processor used for +running the simulation. Here we say that its speed is the same as one of the +processors we are simulating (1Gf), so that 1 second of computation is injected as 1 second in the simulation. .. code-block:: console @@ -570,11 +570,11 @@ as 1 second in the simulation. You may want to use sampling functions or trace replay to reduce this. So in our case (size 3000), the simulation ran for 25 seconds, and the simulated time was 5.57s at the end. -Computation by itself took 24 seconds, and can quickly grow with larger sizes +Computation by itself took 24 seconds, and can quickly grow with larger sizes (as computation is really performed, there will be variability between similar runs). -SMPI provides sampling macros to accelerate simulation by sampling iterations -of large computation loops, and skip computation after a certain amount of iterations, +SMPI provides sampling macros to accelerate simulation by sampling iterations +of large computation loops, and skip computation after a certain amount of iterations, or when the sampling is stable enough. The two macros only slightly differ : @@ -582,7 +582,7 @@ The two macros only slightly differ : - ``SMPI_SAMPLE_GLOBAL`` : the specified number of samples is produced by all processors - ``SMPI_SAMPLE_LOCAL`` : each process executes a specified number of iterations -So if the size of the computed part varies between processes (imbalance), +So if the size of the computed part varies between processes (imbalance), it's safer to use the LOCAL one. To use one of them, replacing the external for loop of the multiply routine: @@ -598,10 +598,10 @@ by: SMPI_SAMPLE_GLOBAL(int i = istart, i <= iend, ++i, 10, 0.005) The first three parameters are the ones from the loop, while the two last ones are for sampling. -They mean that at most 10 iterations will be performed and that the sampling phase can be exited +They mean that at most 10 iterations will be performed and that the sampling phase can be exited earlier if the expected stability is reached after fewer samples. -Now run the code again with various sizes and parameters and check the time taken for the +Now run the code again with various sizes and parameters and check the time taken for the simulation, as well as the resulting simulated time. .. code-block:: console @@ -610,7 +610,7 @@ simulation, as well as the resulting simulated time. The simulation took 1.23698 seconds (after parsing and platform setup) 0.0319454 seconds were actual computation of the application -In this case, the simulation only took 1.2 seconds, while the simulated time +In this case, the simulation only took 1.2 seconds, while the simulated time remained almost identical. The computation results will obviously be altered since most computations are skipped. @@ -628,7 +628,7 @@ We will use the DT benchmark of the NAS suite to illustrate how to avoid such is With 85 processes and class C, the DT simulated benchmark will try to allocate 35GB of memory, which may not be available on the node you are using. -To avoid this we can simply replace the largest calls to malloc and free by calls +To avoid this we can simply replace the largest calls to malloc and free by calls to ``SMPI_SHARED_MALLOC`` and ``SMPI_SHARED_FREE``. This means that all processes will share one single instance of this buffer. As for sampling, results will be altered, and this should not be used for control structures. @@ -647,14 +647,14 @@ Once done, you can now run And simulation should finish without swapping/crashing (Ignore the warning about the return value). -If control structures are also problematic, you can use ``SMPI_PARTIAL_SHARED_MALLOC(size, offsets, offsetscount)`` -macro, which shares only specific parts of the structure between processes, +If control structures are also problematic, you can use ``SMPI_PARTIAL_SHARED_MALLOC(size, offsets, offsetscount)`` +macro, which shares only specific parts of the structure between processes, and use specific memory for the important parts. It can be freed afterward with SMPI_SHARED_FREE. If allocations are performed with malloc or calloc, SMPI (from version 3.25) provides the option ``--cfg=smpi/auto-shared-malloc-shared:n`` which will replace all allocations above size n bytes by -shared allocations. The value has to be carefully selected to avoid smaller control arrays, +shared allocations. The value has to be carefully selected to avoid smaller control arrays, containing data necessary for the completion of the run. Try to run the (non modified) DT example again, with values going from 10 to 100,000 to show that too small values can cause crashes. @@ -662,7 +662,7 @@ too small values can cause crashes. A useful option to identify the largest allocations in the code is ``--cfg=smpi/display-allocs:yes`` (from 3.27). It will display at the end of a (successful) run the largest allocations and their locations, helping pinpoint the targets for sharing, or setting the threshold for automatic ones. -For DT, the process would be to run a smaller class of problems, +For DT, the process would be to run a smaller class of problems, .. code-block:: console diff --git a/docs/source/Tutorial_Model-checking.rst b/docs/source/Tutorial_Model-checking.rst index 8bfbb3e525..a8bebcb141 100644 --- a/docs/source/Tutorial_Model-checking.rst +++ b/docs/source/Tutorial_Model-checking.rst @@ -51,7 +51,7 @@ on Mac OS X yet, so mac users should stick to the docker method for now. .. code-block:: console $ docker image pull simgrid/tuto-mc - $ mkdir ~/tuto-mcsimgrid # or chose another directory to share between your computer and the docker container + $ mkdir ~/tuto-mcsimgrid # or chose another directory to share between your computer and the docker container $ docker run -it --rm --name mcsimgrid --volume ~/tuto-mcsimgrid:/source/tutorial simgrid/tuto-mc bash In the container, you have access to the following directories of interest: @@ -183,7 +183,7 @@ now read it together. It can be split in several parts: reports the first faulty execution it finds: it may not be the shorter possible one. .. code-block:: console - + [0.000000] [mc_ModelChecker/INFO] Counter-example execution trace: [0.000000] [mc_ModelChecker/INFO] [(1)Tremblay (server)] iRecv(dst=(1)Tremblay (server), buff=(verbose only), size=(verbose only)) [0.000000] [mc_ModelChecker/INFO] [(2)Jupiter (client)] iSend(src=(2)Jupiter (client), buff=(verbose only), size=(verbose only)) @@ -213,7 +213,7 @@ now read it together. It can be split in several parts: ==402== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==402== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==402== Command: ./ndet-receive-s4u small_platform.xml --cfg=model-check/replay:1;2;1;1;2;4;1;1;3;1 - ==402== + ==402== [0.000000] [xbt_cfg/INFO] Configuration change: Set 'model-check/replay' to '1;2;1;1;2;4;1;1;3;1' [0.000000] [mc_record/INFO] path=1;2;1;1;2;4;1;1;3;1 [Jupiter:client:(2) 0.000000] [example/INFO] Sending 1 @@ -222,7 +222,7 @@ now read it together. It can be split in several parts: [Jupiter:client:(2) 0.000000] [example/INFO] Sent! [Tremblay:server:(1) 0.000000] /source/tutorial/ndet-receive-s4u.cpp:27: [root/CRITICAL] Assertion value_got == 3 failed (some output ignored) - ==402== + ==402== ==402== Process terminating with default action of signal 6 (SIGABRT): dumping core ==402== at 0x550FCE1: raise (raise.c:51) ==402== by 0x54F9536: abort (abort.c:79) diff --git a/docs/source/XML_reference.rst b/docs/source/XML_reference.rst index 16e0bfbbb3..0e9fa33ce2 100644 --- a/docs/source/XML_reference.rst +++ b/docs/source/XML_reference.rst @@ -27,7 +27,7 @@ Your platform description should follow the specification presented in the SimGrid can simulate the time it takes to read or write data on disk, even if the stored data is not made persistent in any way by SimGrid. This means that your application will correctly be slowed down when doing simulated I/O, but there -is no way to get the data stored this way. +is no way to get the data stored this way. We decided to not model anything beyond raw access in SimGrid because we believe that there is not single way of doing so. We provide an example model of file system as a plugin, (sparsely) documented in :ref:`plugin_filesystem`. @@ -150,7 +150,7 @@ A host is the computing resource on which an actor can run. See :cpp:class:`simg - At time t = 1, the host is turned off (a zero value means OFF) - At time t = 2, the host is turned back on (any other value than zero means ON) - - At time t = 10, the profile is reset (as we are 8 seconds after the last event). Then the host will be turned off + - At time t = 10, the profile is reset (as we are 8 seconds after the last event). Then the host will be turned off again at time t = 11. If your profile does not contain any LOOPAFTER line, then it will @@ -168,8 +168,8 @@ A host is the computing resource on which an actor can run. See :cpp:class:`simg ------ -SimGrid links usually represent one-hop network connections (see :cpp:class:`simgrid::s4u::Link`), i.e., a single wire. -They can also be used to abstract a larger network interconnect, e.g., the entire transcontinental network, into a +SimGrid links usually represent one-hop network connections (see :cpp:class:`simgrid::s4u::Link`), i.e., a single wire. +They can also be used to abstract a larger network interconnect, e.g., the entire transcontinental network, into a single element. **Parent tags:** :ref:`pf_tag_zone` (both leaf zones and inner zones) |br| @@ -310,7 +310,7 @@ and a download link. :``id``: Name of the host. Must be unique on the whole platform. :``speed``: Computational power (in flop/s). - If you use DVFS, provide a comma-separated list of values for each pstate (see :ref:`howto_dvfs`). + If you use DVFS, provide a comma-separated list of values for each pstate (see :ref:`howto_dvfs`). :``bw_in``: Bandwidth of the private downstream link, along with its unit. See :ref:`pf_tag_link`. :``bw_out``: Bandwidth of the private upstream link, along with its @@ -525,8 +525,8 @@ can be obtained easily: just do not set the bb_* attributes. :``suffix``: Each node of the cluster will be suffixed with this suffix :``radical``: Regexp used to generate cluster nodes name. - Syntax: "10-20" will give you 11 machines numbered from 10 to 20, "10-20;2" will give you 12 machines, one with the number 2, others numbered as before. - + Syntax: "10-20" will give you 11 machines numbered from 10 to 20, "10-20;2" will give you 12 machines, one with the number 2, others numbered as before. + The produced number is concatenated between prefix and suffix to form machine names. :``speed``: Same as the ``speed`` attribute of the :ref:`pf_tag_host` tag. :``core``: Same as the ``core`` attribute of the :ref:`pf_tag_host` tag. @@ -543,14 +543,14 @@ can be obtained easily: just do not set the bb_* attributes. :``limiter_link``: Bandwidth for limiter link (if any). This adds a specific link for each node, to set the maximum bandwidth reached when communicating in both directions at the same time. - + In theory this value should be 2*bw for splitduplex links, but in reality this might be less. This value will depend heavily on the communication model, and on the cluster's hardware, so no default value can be set, this has to be measured. - + More details can be obtained in `Toward Better Simulation of MPI Applications on Ethernet/TCP Networks `_ :``loopback_bw``: Bandwidth for loopback (if any). See :ref:`pf_tag_link` section for syntax/details. If loopback_bw and loopback_lat attributes are omitted, no loopback link is created and all intra-node communication will use the main network link of the node. - + The sharing policy of a loopback link is **FATPIPE** :ref:`pf_tag_link`. :``loopback_lat``: Latency for loopback (if any). See loopback_bw for more info. :``topology``: Network topology to use. @@ -562,7 +562,7 @@ can be obtained easily: just do not set the bb_* attributes. :``topo_parameters``: Specific parameters to pass for the topology defined in the topology tag. For torus networks, comma-separated list of the number of nodes in each dimension of the torus. - + Please refer to :ref:`platform_examples`. @@ -593,7 +593,7 @@ The second example creates one router and 100 machines with the following names: c-99.me .. note:: - + The router name is defined as the resulting string: prefix + clusterId + "_router" + suffix. In this case: *my_cluster_1_router* and *my_cluster_2_router.me*. @@ -622,8 +622,8 @@ and routers yourself; see our examples below. :``prefix``: Each node of the cabinet has to have a name. This name will be prefixed with this prefix. :``suffix``: Each node of the cabinet will be suffixed with this suffix. :``radical``: Regexp used to generate cabinet nodes name. - Syntax: "10-20" will give you 11 machines numbered from 10 to 20, "10-20;2" will give you 12 machines, one with the number 2, others numbered as before. - + Syntax: "10-20" will give you 11 machines numbered from 10 to 20, "10-20;2" will give you 12 machines, one with the number 2, others numbered as before. + The produced number is concatenated between prefix and suffix to form machine names. :``speed``: Same as the ``speed`` attribute of the :ref:`pf_tag_host` tag. :``bw``: Bandwidth for the links between nodes and backbone (if any). See the :ref:`pf_tag_link` for syntax/details. diff --git a/docs/source/_templates/breadcrumbs.html b/docs/source/_templates/breadcrumbs.html index 631fd76935..0ce11e7e27 100644 --- a/docs/source/_templates/breadcrumbs.html +++ b/docs/source/_templates/breadcrumbs.html @@ -5,11 +5,11 @@ {% block breadcrumbs_aside %}
  • {% if hasdoc(pagename) and pagename != "search" and pagename != "genindex" %} - {# TODO: How to rule out all java pages? + {# TODO: How to rule out all java pages? # (not re.match(pagename, "java/org/simgrid")) # fails because re is not imported #} - + {{ _('Edit on FramaGit') }} {% endif %} -
    • + {% endblock %} diff --git a/docs/source/app_msg.rst b/docs/source/app_msg.rst index 0c14d15b50..d3dc33e474 100644 --- a/docs/source/app_msg.rst +++ b/docs/source/app_msg.rst @@ -32,7 +32,7 @@ The basic workflow is the following: - Initialize the library with :c:macro:`MSG_init` - Create a platform (usually by parsing a file with :cpp:func:`MSG_create_environment`) - Register the functions that your processes are supposed to run with - :cpp:func:`MSG_function_register` (and maybe :cpp:func:`MSG_function_register_default`) + :cpp:func:`MSG_function_register` (and maybe :cpp:func:`MSG_function_register_default`) - Launch your processes from a deployment file with :cpp:func:`MSG_launch_application` - Run the simulation with :cpp:func:`MSG_main` @@ -167,7 +167,7 @@ Task structure of MSG :cpp:type:`msg_task_t` and associated functions. .. doxygenfunction:: MSG_task_set_name .. doxygenfunction:: MSG_task_set_priority - + Mailbox Management ================== @@ -204,7 +204,7 @@ Barriers Semaphores ---------- - + .. doxygentypedef:: msg_sem_t .. doxygenfunction:: MSG_sem_acquire .. doxygenfunction:: MSG_sem_acquire_timeout @@ -257,7 +257,7 @@ Network Zone (:cpp:type:`msg_netzone_t`) and associated functions. Java bindings ************* -This section describes jMSG, the Java API to Simgrid. This API mimics +This section describes jMSG, the Java API to Simgrid. This API mimics :ref:`MSG `, which is a simple yet somehow realistic interface. The full reference documentation is provided at the end of this page. @@ -289,7 +289,7 @@ For example: .. code-block:: console $ cd examples/deprecated/java - $ java -classpath ../../simgrid.jar:. .:../../simgrid.jar app.pingpong.Main ../platforms/platform.xml + $ java -classpath ../../simgrid.jar:. .:../../simgrid.jar app.pingpong.Main ../platforms/platform.xml Any SimGrid simulation (java or not) is usually constituted of several kind of actors or processes (classes extending @c Msg.Process) that @@ -336,7 +336,7 @@ When using jMSG, your program can crash for 3 main reasons: you should read carefully MSG samples and/or documentation. - Something has crashed in the C part. Okay, here comes the tricky thing. It happens mainly for 2 reasons: - + - When something goes wrong in your simulation, sometimes the C part stops because you used SimGrid incorrectly, and JNI bindings are not fond of that. It means that you'll have something that looks ugly, but you should be able diff --git a/docs/source/app_s4u.rst b/docs/source/app_s4u.rst index 01e3c22c53..b8b784978b 100644 --- a/docs/source/app_s4u.rst +++ b/docs/source/app_s4u.rst @@ -21,14 +21,14 @@ abstract algorithms in the domains of Cloud, P2P, HPC, IoT, and similar settings. Since v3.20 (June 2018), S4U is the way to go for long-term -projects. It is feature complete, but may still evolve slightly in +projects. It is feature complete, but may still evolve slightly in future releases. It can already be used to do everything that can be done in SimGrid, but you may have to adapt your code in future releases. When this happens, compiling your code will produce deprecation warnings for 4 releases (one year) before the removal of -the old symbols. +the old symbols. If you want an API that will never ever evolve in the future, you -should use the :ref:`deprecated MSG API ` instead. +should use the :ref:`deprecated MSG API ` instead. Main Concepts ************* @@ -144,7 +144,7 @@ Activities ********** Activities represent the actions that consume a resource, such as a -:ref:`Comm ` that consumes the *transmitting power* of +:ref:`Comm ` that consumes the *transmitting power* of :ref:`Link ` resources, or an :ref:`Exec ` that consumes the *computing power* of :ref:`Host ` resources. See also the :ref:`full API ` below. @@ -171,10 +171,10 @@ Finally, to wait at most until a specified time limit, use Every kind of activity can be asynchronous: - - :ref:`s4u::CommPtr ` are created with + - :ref:`s4u::CommPtr ` are created with :cpp:func:`s4u::Mailbox::put_async() ` and :cpp:func:`s4u::Mailbox::get_async() `. - - :ref:`s4u::IoPtr ` are created with + - :ref:`s4u::IoPtr ` are created with :cpp:func:`s4u::Disk::read_async() ` and :cpp:func:`s4u::Disk::write_async() `. - :ref:`s4u::ExecPtr ` are created with @@ -194,11 +194,11 @@ vector of mailboxes. :dedent: 4 Then, you start all the communications that should occur concurrently with -:cpp:func:`s4u::Mailbox::put_async() `. +:cpp:func:`s4u::Mailbox::put_async() `. Finally, the actor waits for the completion of all of them at once -with -:cpp:func:`s4u::Comm::wait_all() `. - +with +:cpp:func:`s4u::Comm::wait_all() `. + .. literalinclude:: ../../examples/cpp/comm-waitall/s4u-comm-waitall.cpp :language: c++ :start-after: put-begin @@ -210,12 +210,12 @@ with Activities Life cycle ===================== -Sometimes, you want to change the setting of an activity before it even starts. +Sometimes, you want to change the setting of an activity before it even starts. .. todo:: write this section .. _s4u_mailbox: - + Mailboxes ********* @@ -233,9 +233,9 @@ but only to find the contact with which you want to communicate. They are similar to many common things: The phone number, which allows the caller to find the receiver. The Twitter hashtag, which helps -senders and receivers to find each other. In TCP, the pair +senders and receivers to find each other. In TCP, the pair ``{host name, host port}`` to which you can connect to find your peer. -In HTTP, URLs through which the clients can connect to the servers. +In HTTP, URLs through which the clients can connect to the servers. In ZeroMQ, the queues are used to match senders and receivers. One big difference with most of these systems is that no actor is the @@ -259,9 +259,9 @@ is consumed by the first receiver. A big difference with the ZeroMQ queues is that you cannot filter on the data you want to get from the mailbox. To model such settings in SimGrid, you'd have one mailbox per potential topic, and subscribe -to each topic individually with a +to each topic individually with a :cpp:func:`get_async() ` on each mailbox. -Then, use :cpp:func:`Comm::wait_any() ` +Then, use :cpp:func:`Comm::wait_any() ` to get the first message on any of the mailboxes you are subscribed to. The mailboxes are not located on the network, and you can access @@ -314,14 +314,14 @@ Declaring a Receiving Actor The last twist is that by default in the simulator, the data starts to be exchanged only when both the sender and the receiver are announced (it waits until both :cpp:func:`put() ` -and :cpp:func:`get() ` are posted). +and :cpp:func:`get() ` are posted). In TCP, since you establish connections beforehand, the data starts to flow as soon as the sender posts it, even if the receiver did not post -its :cpp:func:`put() ` yet. +its :cpp:func:`put() ` yet. To model this in SimGrid, you can declare a specific receiver to a -given mailbox (with the function -:cpp:func:`set_receiver() `). +given mailbox (with the function +:cpp:func:`set_receiver() `). That way, any :cpp:func:`put() ` posted to that mailbox will start as soon as possible, and the data will already be there on the receiver host when the receiver actor @@ -372,14 +372,14 @@ Here is a little example: .. code-block:: cpp - void myFunc() + void myFunc() { simgrid::s4u::MutexPtr mutex = simgrid::s4u::Mutex::create(); // Too bad we cannot use `new` mutex->lock(); // use the mutex as a simple reference // bla bla - mutex->unlock(); - + mutex->unlock(); + } // The mutex gets automatically freed because the only existing reference gets out of scope Note that Mailboxes, Hosts, and Links are not handled through smart @@ -506,7 +506,7 @@ Querying info .. doxygenfunction:: simgrid::s4u::Actor::get_ppid .. doxygenfunction:: simgrid::s4u::Actor::get_properties() const .. doxygenfunction:: simgrid::s4u::Actor::get_property(const std::string &key) const - .. doxygenfunction:: simgrid::s4u::Actor::set_property(const std::string &key, const std::string &value) + .. doxygenfunction:: simgrid::s4u::Actor::set_property(const std::string &key, const std::string &value) .. doxygenfunction:: simgrid::s4u::Actor::get_host .. doxygenfunction:: simgrid::s4u::Actor::set_host @@ -515,7 +515,7 @@ Querying info .. doxygenfunction:: simgrid::s4u::Actor::get_impl .. group-tab:: Python - + .. autoattribute:: simgrid.Actor.name .. autoattribute:: simgrid.Actor.host .. autoattribute:: simgrid.Actor.pid @@ -811,7 +811,7 @@ Initialization .. doxygenfunction:: simgrid::s4u::Engine::register_function(const std::string &name, const kernel::actor::ActorCodeFactory &factory) .. group-tab:: Python - + .. automethod:: simgrid.Engine.load_deployment .. automethod:: simgrid.Engine.load_platform .. automethod:: simgrid.Engine.register_actor @@ -836,7 +836,7 @@ Run the simulation .. doxygenfunction:: simgrid::s4u::Engine::run .. group-tab:: Python - + .. automethod:: simgrid.Engine.get_clock .. automethod:: simgrid.Engine.run @@ -947,7 +947,7 @@ Basic management idiom on mailboxes because they are internal objects to the simulation engine. Once created, there is no way to destroy a mailbox before the end of the simulation. - + .. doxygenfunction:: simgrid::s4u::Mailbox::by_name(const std::string &name) .. group-tab:: Python @@ -965,7 +965,7 @@ Basic management .. code-block:: C #include - + .. doxygentypedef:: sg_mailbox_t .. doxygentypedef:: const_sg_mailbox_t @@ -1054,7 +1054,7 @@ See :ref:`s4u_receiving_actor`. .. group-tab:: C .. doxygenfunction:: sg_mailbox_set_receiver(const char *alias) - + .. _API_s4u_Resource: ========= @@ -1082,8 +1082,8 @@ Basic management Note that there is no DiskPtr type and that you cannot use the RAII idiom on disks because SimGrid does not allow (yet) to create nor - destroy resources once the simulation is started. - + destroy resources once the simulation is started. + .. doxygenfunction:: simgrid::s4u::Disk::seal() .. group-tab:: Python @@ -1170,7 +1170,7 @@ Basic management Note that there is no HostPtr type, and that you cannot use the RAII idiom on hosts because SimGrid does not allow (yet) to create nor - destroy resources once the simulation is started. + destroy resources once the simulation is started. .. doxygenfunction:: simgrid::s4u::Host::destroy() .. doxygenfunction:: simgrid::s4u::Host::seal() @@ -1426,7 +1426,7 @@ Basic management Note that there is no LinkPtr type and that you cannot use the RAII idiom on hosts because SimGrid does not allow (yet) to create nor - destroy resources once the simulation is started. + destroy resources once the simulation is started. .. doxygenfunction:: simgrid::s4u::Link::seal() @@ -1606,7 +1606,7 @@ Basic management Note that there is no NetZonePtr type and that you cannot use the RAII idiom on network zones because SimGrid does not allow (yet) to create nor - destroy resources once the simulation is started. + destroy resources once the simulation is started. .. doxygenfunction:: simgrid::s4u::NetZone::seal @@ -2068,7 +2068,7 @@ also start direct communications as shown below. .. doxygenfunction:: simgrid::s4u::Comm::sendto .. doxygenfunction:: simgrid::s4u::Comm::sendto_init .. doxygenfunction:: simgrid::s4u::Comm::sendto_async - + .. doxygenfunction:: simgrid::s4u::Comm::cancel .. doxygenfunction:: simgrid::s4u::Comm::start .. doxygenfunction:: simgrid::s4u::Comm::test @@ -2167,7 +2167,7 @@ Querying info .. autoattribute:: simgrid.Exec.remaining_ratio .. group-tab:: C - + .. doxygenfunction:: sg_exec_set_bound(sg_exec_t exec, double bound) .. doxygenfunction:: sg_exec_get_name(const_sg_exec_t exec) .. doxygenfunction:: sg_exec_set_name(sg_exec_t exec, const char* name) @@ -2198,7 +2198,7 @@ Life cycle .. automethod:: simgrid.Exec.wait .. group-tab:: C - + .. doxygenfunction:: sg_exec_start(sg_exec_t exec) .. doxygenfunction:: sg_exec_cancel(sg_exec_t exec); .. doxygenfunction:: sg_exec_test(sg_exec_t exec); diff --git a/docs/source/app_smpi.rst b/docs/source/app_smpi.rst index a62509fd42..801a244f1b 100644 --- a/docs/source/app_smpi.rst +++ b/docs/source/app_smpi.rst @@ -298,7 +298,7 @@ MPI_Scatter - automatic (experimental): use an automatic self-benchmarking algorithm - ompi_basic_linear: basic linear scatter - ompi_binomial: binomial tree scatter - - mvapich2_two_level_direct: SMP aware algorithm, with an intra-node stage (default set to mpich selector), and then a basic linear inter node stage. Use mvapich2 selector to change these to tuned algorithms for Stampede cluster. + - mvapich2_two_level_direct: SMP aware algorithm, with an intra-node stage (default set to mpich selector), and then a basic linear inter node stage. Use mvapich2 selector to change these to tuned algorithms for Stampede cluster. - mvapich2_two_level_binomial: SMP aware algorithm, with an intra-node stage (default set to mpich selector), and then a binomial phase. Use mvapich2 selector to change these to tuned algorithms for Stampede cluster. MPI_Reduce @@ -688,12 +688,12 @@ iterations. These samples are done per processor with SMPI_SAMPLE_LOCAL, and shared between all processors with SMPI_SAMPLE_GLOBAL. Of course, none of this will work if the execution time of your loop iteration are not stable. If some parameters have an -incidence on the timing of a kernel, and if they are reused often -(same kernel launched with a few different sizes during the run, for example), -SMPI_SAMPLE_LOCAL_TAG and SMPI_SAMPLE_GLOBAL_TAG can be used, with a tag -as last parameter, to differentiate between calls. The tag is a character +incidence on the timing of a kernel, and if they are reused often +(same kernel launched with a few different sizes during the run, for example), +SMPI_SAMPLE_LOCAL_TAG and SMPI_SAMPLE_GLOBAL_TAG can be used, with a tag +as last parameter, to differentiate between calls. The tag is a character chain crafted by the user, with a maximum size of 128, and should include -what is necessary to group calls of a given size together. +what is necessary to group calls of a given size together. This feature is demoed by the example file `examples/smpi/NAS/ep.c `_ @@ -750,13 +750,13 @@ Some show how to simply run MPI code in SimGrid, how to use the tracing/replay mechanism or how to use plugins written in S4U to extend the simulator abilities. -Another source of examples lay in the SimGrid archive, under +Another source of examples lay in the SimGrid archive, under `teshsuite/smpi `_. They are not in the ``examples`` directory because they probably don't constitute pedagogical examples. Instead, they are intended to stress our implementation during the tests. Some of you may be interested anyway. - + But the best source of SMPI examples is certainly the `proxy app `_ external project. Proxy apps are scale models of real, massive HPC applications: each of diff --git a/docs/source/community.rst b/docs/source/community.rst index d380ee13e1..534f659575 100644 --- a/docs/source/community.rst +++ b/docs/source/community.rst @@ -29,7 +29,7 @@ to us and say hello! We love earing about how people use SimGrid. framework, and you never know who have the time and knowledge to answer your question, so please keep messages on the public mailing list. - + - If you want to chat with the community, join us on `Mattermost `_. Be warned that even if many people are connected to the channel, they may not @@ -42,13 +42,13 @@ to us and say hello! We love earing about how people use SimGrid. non-french speaker are connected, we usually chat in french on these channel, but we do switch back to english when we have a guest. - + - Asking your question on `StackOverflow `_ is also a good idea, as this site is very well indexed. We answer questions there too (don't forget to use the SimGrid tag in your question so that we can see - it), and they remain usable for the next users. + it), and they remain usable for the next users. Giving back to SimGrid ---------------------- @@ -59,28 +59,28 @@ are some ideas, but if you have new ones, feel free to share them with us. Provide fresh-eyes feedback ^^^^^^^^^^^^^^^^^^^^^^^^^^^ -We are working on the project since years. We take for granted things that are hard to infer at first, and traps we don't even see anymore. +We are working on the project since years. We take for granted things that are hard to infer at first, and traps we don't even see anymore. Likewise, it's hard for us to maintain the documentation uptodate with the current situation, because we don't rely on the doc when navigating the project. -This is why your first impression as a newcomer to the project is utterly precious for us. +This is why your first impression as a newcomer to the project is utterly precious for us. Please make sure to write a `discovery report `_ to enlight us. You can send it either as a bug report, as a mail on the list or simply post it as is to the Mattermost channel. Spread the word ^^^^^^^^^^^^^^^ -A simple way to help the SimGrid project is to **use SimGrid for your research, and say so**. -`Cite the SimGrid framework`_ in your papers and speak of it with your colleagues to spread the word. +A simple way to help the SimGrid project is to **use SimGrid for your research, and say so**. +`Cite the SimGrid framework`_ in your papers and speak of it with your colleagues to spread the word. The number of publications enabled by SimGrid is really important when asking for further fundings to sustain the project: -The more you use the framework, the better for us. +The more you use the framework, the better for us. Add a link to the `SimGrid homepage `_ on your site to improve our ranking in search engines. You can also **help us constituting an active and welcoming user community**. Answer to the question sent to the mailing lists if you can, gently pointing to -the relevant part of the documentation on need, and help newscomers becoming part of our community too. +the relevant part of the documentation on need, and help newscomers becoming part of our community too. Finally, you can invite us for a talk on SimGrid to events you organize. -We have various format, ranging from a focused `20 minute talks `_ -to a `45mn dense tutorial `_, +We have various format, ranging from a focused `20 minute talks `_ +to a `45mn dense tutorial `_, to a `2 hours seminar `_, or even to `multi-days events `_. Note that even if most of these examples are from the same individual, several people in the team can present the project. @@ -98,11 +98,11 @@ find**, be it a typo in the documentation, a paragraph that needs to be reworded, a bug in the code, or any other problem. The best way to do so is to open an issue on our `Bug Tracker `_ so -that we don't forget about it. +that we don't forget about it. The worst way to report such issues is to go through private emails. These are unreliable, and we are trying to develop SimGrid openly, so -private discussions are to be avoided if possible. +private discussions are to be avoided if possible. If you can provide a patch fixing the issue you report, that's even better. If you cannot, then you need to give us a minimal working @@ -135,8 +135,8 @@ could be included to SimGrid. Modeling accurately a given platform is a difficult work, which outcome is very precious to us. Or maybe you developed an independent tool on top of SimGrid. We'd -love helping you gaining visibility by listing it in our -`Contrib `_. +love helping you gaining visibility by listing it in our +`Contrib `_. Possible Enhancements ^^^^^^^^^^^^^^^^^^^^^ diff --git a/docs/source/intl.rst b/docs/source/intl.rst index 2216ed32f7..2053c997bf 100644 --- a/docs/source/intl.rst +++ b/docs/source/intl.rst @@ -1,12 +1,11 @@ - 基于SimGrid提供的模拟器工具包, 构建一个异构多核处理器的仿真环境. -In Liu LD, Wu YL. List Scheduling Algorithm of Dependent Tasks Based on HEFT and CPOP. +In Liu LD, Wu YL. List Scheduling Algorithm of Dependent Tasks Based on HEFT and CPOP. Computer Systems and Applications, 2019, 28(3): 118-125 (in Chinese). http://www.c-s-a.org.cn/1003-3254/6807.html -Таким образом, единственнымпакетом моделирования, соответствующимнашим требо-ваниям, является SimGrid. -In V. Airiian, V. Korenkov and A. Nechaevskiy. Modelling LIT Cloud Infrastructure at JINR and Evaluating the Model. -7th International Conference Distributed Computing and Grid-technologies in Science and Education, 2016 (in Russian). +Таким образом, единственнымпакетом моделирования, соответствующимнашим требо-ваниям, является SimGrid. +In V. Airiian, V. Korenkov and A. Nechaevskiy. Modelling LIT Cloud Infrastructure at JINR and Evaluating the Model. +7th International Conference Distributed Computing and Grid-technologies in Science and Education, 2016 (in Russian). http://ceur-ws.org/Vol-1787/74-79-paper-11.pdf Os experimentos foram feitos utilizando o Simgrid, que é um simulador amplamente utilizado na avaliação de sistemas distribuı́dos. @@ -14,7 +13,7 @@ In J.F. de Souza, H. Senger & F.A. Silva. Escalabilidade de Aplicações Bag-of- 37th Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos, 2019 (in Portuguese). Dado [...] los modelos de rendimiento (codelets) de cada una de las rutinas computacionales [...], se podría hacer uso del simulador SimGrid para estimar el rendimiento [...]. -In D. Jesus Camara Moreno. Técnicas de optimización de rutinas paralelas de álgebra lineal en sistemas heterogéneos. +In D. Jesus Camara Moreno. Técnicas de optimización de rutinas paralelas de álgebra lineal en sistemas heterogéneos. PhD dissertation of the Universidad de Murcia, Spain, 2020 (in Spanish). https://digitum.um.es/digitum/bitstream/10201/101964/1/Tesis.pdf @@ -24,7 +23,7 @@ PhD dissertation of the Universidad Nactional De San Augustin, Peru, 2018 (in Sp http://repositorio.unsa.edu.pe/bitstream/handle/UNSA/7593/ISDmaalah.pdf SimGrid を用いて並列計算ベンチマークの演算時間，通信時間，実行時間をシミュレーションし，特に集合通信を多用するアプリケーションでは， -In Y. Urino, K. Mizutani, T. Usuki and S. Nakamura. Parallel computing systems with wavelength routing interconnect "Optical Hub". +In Y. Urino, K. Mizutani, T. Usuki and S. Nakamura. Parallel computing systems with wavelength routing interconnect "Optical Hub". Research Report of the Information Processing Society of Japan, 2019 (in Japanese). https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=198402&item_no=1&page_id=13&block_id=8 diff --git a/docs/source/tuto_disk/Dockerfile b/docs/source/tuto_disk/Dockerfile index 5a58b42ab8..468451b9f4 100644 --- a/docs/source/tuto_disk/Dockerfile +++ b/docs/source/tuto_disk/Dockerfile @@ -46,7 +46,7 @@ RUN cd /source && git clone --depth=1 https://framagit.org/simgrid/simgrid.git s cmake -DCMAKE_INSTALL_PREFIX=/usr/ -Denable_documentation=OFF -Denable_smpi=ON -Denable_compile_optimizations=ON . && \ make -j4 install -## compile +## compile RUN cd /source/simgrid.git/docs/source/tuto_disk && \ cmake . &&\ make diff --git a/docs/source/tuto_disk/analysis.irst b/docs/source/tuto_disk/analysis.irst index dfc89126e7..d782b38f83 100644 --- a/docs/source/tuto_disk/analysis.irst +++ b/docs/source/tuto_disk/analysis.irst @@ -22,7 +22,7 @@ in IO operations (Fig. 5 to 7). - Link for data: `https://figshare.com/articles/dataset/Companion_of_the_SimGrid_storage_modeling_article/1175156 `_ -**Disclaimer**: +**Disclaimer**: - The purpose of this document is to illustrate how we can extract data from experiments and inject on SimGrid. However, the @@ -54,7 +54,7 @@ Scripts ------- We use a special method to create non-uniform histograms to represent -the noise in IO operations. +the noise in IO operations. Unable to install the library properly, I copied the important methods here. @@ -708,7 +708,7 @@ the real platform. sg_df[sg_df$op=="write" & sg_df$flows ==1,]$method="" ggplot(data=sg_df, aes(x=flows, y=bw, color=op)) + theme_bw() + - geom_point(alpha=.3) + + geom_point(alpha=.3) + geom_smooth(data=sg_df[sg_df$method=="loess",], color="black", method=loess,se=TRUE,fullrange=T) + geom_smooth(data=sg_df[sg_df$method=="lm",], color="black", method=lm,se=TRUE) + geom_errorbar(data=sg_dfd, aes(x=flows, y=mean, ymin=mean-2*se, ymax=mean+2*se),color="black",width=.6) + diff --git a/docs/source/tuto_disk/analysis.org b/docs/source/tuto_disk/analysis.org index 04d6d88da5..ee082ba512 100644 --- a/docs/source/tuto_disk/analysis.org +++ b/docs/source/tuto_disk/analysis.org @@ -23,7 +23,7 @@ - Link for paper: https://hal.inria.fr/hal-01197128 - Link for data: https://figshare.com/articles/dataset/Companion_of_the_SimGrid_storage_modeling_article/1175156 - *Disclaimer*: + *Disclaimer*: - The purpose of this document is to illustrate how we can extract data from experiments and inject on SimGrid. However, the data shown on this page may *not* reflect the reality. @@ -45,7 +45,7 @@ *** Scripts We use a special method to create non-uniform histograms to represent - the noise in IO operations. + the noise in IO operations. Unable to install the library properly, I copied the important methods here. @@ -55,21 +55,21 @@ #+begin_src R :results output :session *R* :exports none #' Variable-width (dagonally cut) histogram #' -#' +#' #' When constructing a histogram, it is common to make all bars the same width. #' One could also choose to make them all have the same area. #' These two options have complementary strengths and weaknesses; the equal-width histogram oversmooths in regions of high density, and is poor at identifying sharp peaks; the equal-area histogram oversmooths in regions of low density, and so does not identify outliers. -#' We describe a compromise approach which avoids both of these defects. We regard the histogram as an exploratory device, rather than as an estimate of a density. -#' @title Diagonally Cut Histogram +#' We describe a compromise approach which avoids both of these defects. We regard the histogram as an exploratory device, rather than as an estimate of a density. +#' @title Diagonally Cut Histogram #' @param x is a numeric vector (the data) #' @param a is the scaling factor, default is 5 * IQR #' @param nbins is the number of bins, default is assigned by the Stuges method -#' @param rx is the range used for the left of the left-most bin to the right of the right-most bin +#' @param rx is the range used for the left of the left-most bin to the right of the right-most bin #' @param eps used to set artificial bound on min width / max height of bins as described in Denby and Mallows (2009) on page 24. -#' @param xlab is label for the x axis +#' @param xlab is label for the x axis #' @param plot = TRUE produces the plot, FALSE returns the heights, breaks and counts #' @param lab.spikes = TRUE labels the \% of data in the spikes -#' @return list with two elements, heights of length n and breaks of length n+1 indicating the heights and break points of the histogram bars. +#' @return list with two elements, heights of length n and breaks of length n+1 indicating the heights and break points of the histogram bars. #' @author Lorraine Denby, Colin Mallows #' @references Lorraine Denby, Colin Mallows. Journal of Computational and Graphical Statistics. March 1, 2009, 18(1): 21-31. doi:10.1198/jcgs.2009.0002. dhist<-function(x, a=5*iqr(x), @@ -97,7 +97,7 @@ # upper and lower corners in the ecdf ylower <- yupper - a/n # - cmtx <- cbind(cut(yupper, breaks = ybr), cut(yupper, breaks = + cmtx <- cbind(cut(yupper, breaks = ybr), cut(yupper, breaks = ybr, left.include = TRUE), cut(ylower, breaks = ybr), cut(ylower, breaks = ybr, left.include = TRUE)) cmtx[1, 3] <- cmtx[1, 4] <- 1 @@ -177,7 +177,7 @@ amt.txt<-0 end.y<-(-10000) if(plot) { - barplot(heights, abs(diff(xbr)), space = 0, density = -1, xlab = + barplot(heights, abs(diff(xbr)), space = 0, density = -1, xlab = xlab, plot = TRUE, xaxt = "n",yaxt='n') at <- pretty(xbr) axis(1, at = at - xbr[1], labels = as.character(at)) @@ -214,7 +214,7 @@ #' Calculates the 25th and 75th quantiles given a vector x; used in function \link{dhist}. #' @title Interquartile range #' @param x vector -#' @return numeric vector of length 2, with the 25th and 75th quantiles of input vector x. +#' @return numeric vector of length 2, with the 25th and 75th quantiles of input vector x. iqr<-function(x){ return(diff(quantile(x, c(0.25, 0.75), na.rm = TRUE))) } @@ -364,7 +364,7 @@ from the one in the paper. Probably, we need to further clean the available data to obtain exaclty the same results. - #+begin_src R :results output graphics :file fig/griffon_deg.png :exports both :width 600 :height 400 :session *R* + #+begin_src R :results output graphics :file fig/griffon_deg.png :exports both :width 600 :height 400 :session *R* ggplot(data=dfc,aes(x=Jobs,y=BW, color=Operation)) + theme_bw() + geom_point(alpha=.3) + geom_point(data=dfrange, size=0) + @@ -388,7 +388,7 @@ toJSON(IO_INFO, pretty = TRUE) #+end_src - + ***** Write Same for write operations. @@ -400,7 +400,7 @@ IO_INFO[["griffon"]][["degradation"]][["write"]] = c(mean_job_1$mean, predict(model,data.frame(Jobs=seq(2,15)))) toJSON(IO_INFO, pretty = TRUE) #+end_src - + **** Modeling read/write bandwidth variability @@ -414,7 +414,7 @@ ***** Read First, we present the histogram for read operations. - #+begin_src R :results output graphics :file fig/griffon_read_dhist.png :exports both :width 600 :height 400 :session *R* + #+begin_src R :results output graphics :file fig/griffon_read_dhist.png :exports both :width 600 :height 400 :session *R* griffon_read = df %>% filter(grepl("^Griffon", Cluster)) %>% filter(Operation == "Read") %>% select(Bwi) dhist(1/griffon_read$Bwi) #+end_src @@ -431,7 +431,7 @@ ***** Write Same analysis for write operations. - #+begin_src R :results output graphics :file fig/griffon_write_dhist.png :exports both :width 600 :height 400 :session *R* + #+begin_src R :results output graphics :file fig/griffon_write_dhist.png :exports both :width 600 :height 400 :session *R* griffon_write = df %>% filter(grepl("^Griffon", Cluster)) %>% filter(Operation == "Write") %>% select(Bwi) dhist(1/griffon_write$Bwi) #+end_src @@ -475,7 +475,7 @@ ***** Read - #+begin_src R :results output graphics :file fig/edel_read_dhist.png :exports both :width 600 :height 400 :session *R* + #+begin_src R :results output graphics :file fig/edel_read_dhist.png :exports both :width 600 :height 400 :session *R* edel_read = df %>% filter(grepl("^Edel", Cluster)) %>% filter(Operation == "Read") %>% select(Bwi) dhist(1/edel_read$Bwi) #+end_src @@ -490,7 +490,7 @@ #+end_src ***** Write - #+begin_src R :results output graphics :file fig/edel_write_dhist.png :exports both :width 600 :height 400 :session *R* + #+begin_src R :results output graphics :file fig/edel_write_dhist.png :exports both :width 600 :height 400 :session *R* edel_write = df %>% filter(grepl("^Edel", Cluster)) %>% filter(Operation == "Write") %>% select(Bwi) dhist(1/edel_write$Bwi) @@ -582,15 +582,15 @@ each case. We can see that the graphics are quite similar to the ones obtained in the real platform. - #+begin_src R :results output graphics :file fig/simgrid_results.png :exports both :width 600 :height 400 :session *R* + #+begin_src R :results output graphics :file fig/simgrid_results.png :exports both :width 600 :height 400 :session *R* sg_df = read.csv("./simgrid_disk.csv") sg_df = sg_df %>% group_by(disk, op, flows) %>% mutate(bw=((size*flows)/elapsed)/10^6, method=if_else(disk=="edel" & op=="read", "loess", "lm")) sg_dfd = sg_df %>% filter(flows==1 & op=="write") %>% group_by(disk, op, flows) %>% summarize(mean = mean(bw), sd = sd(bw), se=sd/sqrt(n())) sg_df[sg_df$op=="write" & sg_df$flows ==1,]$method="" - + ggplot(data=sg_df, aes(x=flows, y=bw, color=op)) + theme_bw() + - geom_point(alpha=.3) + + geom_point(alpha=.3) + geom_smooth(data=sg_df[sg_df$method=="loess",], color="black", method=loess,se=TRUE,fullrange=T) + geom_smooth(data=sg_df[sg_df$method=="lm",], color="black", method=lm,se=TRUE) + geom_errorbar(data=sg_dfd, aes(x=flows, y=mean, ymin=mean-2*se, ymax=mean+2*se),color="black",width=.6) + diff --git a/docs/source/tuto_disk/init.el b/docs/source/tuto_disk/init.el index 2129abf378..a5cadeb89f 100644 --- a/docs/source/tuto_disk/init.el +++ b/docs/source/tuto_disk/init.el @@ -1,11 +1,10 @@ - (package-initialize) (add-to-list 'package-archives - '("gnu" . "https://elpa.gnu.org/packages/")) + '("gnu" . "https://elpa.gnu.org/packages/")) (add-to-list 'package-archives - '("melpa-stable" . "https://stable.melpa.org/packages/")) + '("melpa-stable" . "https://stable.melpa.org/packages/")) (add-to-list 'package-archives - '("melpa" . "https://melpa.org/packages/")) + '("melpa" . "https://melpa.org/packages/")) (add-to-list 'load-path "/source/ox-rst.git/") (setq package-archive-priorities '(("melpa-stable" . 100) ("melpa" . 50) @@ -27,8 +26,8 @@ (global-set-key (kbd "C-c l") 'org-store-link) -;; In org-mode 9 you need to have #+PROPERTY: header-args :eval never-export -;; in the beginning or your document to tell org-mode not to evaluate every +;; In org-mode 9 you need to have #+PROPERTY: header-args :eval never-export +;; in the beginning or your document to tell org-mode not to evaluate every ;; code block every time you export. (setq org-confirm-babel-evaluate nil) ;; Do not ask for confirmation all the time!! @@ -55,7 +54,7 @@ )) (setq org-src-preserve-indentation t) -(add-hook 'org-babel-after-execute-hook 'org-display-inline-images) +(add-hook 'org-babel-after-execute-hook 'org-display-inline-images) (add-hook 'org-mode-hook 'org-display-inline-images) (add-hook 'org-mode-hook 'org-babel-result-hide-all) diff --git a/examples/README.rst b/examples/README.rst index d55b6e293a..f28c77cafd 100644 --- a/examples/README.rst +++ b/examples/README.rst @@ -10,7 +10,7 @@ Examples SimGrid comes with an extensive set of examples, documented on this page. Most of them only demonstrate one single feature, with some -larger exemplars listed below. +larger exemplars listed below. The C++ examples can be found under examples/cpp while python examples are in examples/python. Each such directory contains the source code (also listed @@ -38,32 +38,32 @@ Starting and Stopping Actors also create them directly from your code. .. tabs:: - + .. example-tab:: examples/cpp/actor-create/s4u-actor-create.cpp - + You create actors either: - + - Directly with :cpp:func:`simgrid::s4u::Actor::create` - From XML with :cpp:func:`simgrid::s4u::Engine::register_actor` (if your actor is a class) or :cpp:func:`simgrid::s4u::Engine::register_function` (if your actor is a function) and then :cpp:func:`simgrid::s4u::Engine::load_deployment` - + .. example-tab:: examples/python/actor-create/actor-create.py - + You create actors either: - + - Directly with :py:func:`simgrid.Actor.create()` - From XML with :py:func:`simgrid.Engine.register_actor()` and then :py:func:`simgrid.Engine.load_deployment()` - + .. example-tab:: examples/c/actor-create/actor-create.c - + You create actors either: - + - Directly with :cpp:func:`sg_actor_create` followed by :cpp:func:`sg_actor_start`. - From XML with :cpp:func:`simgrid_register_function` and then :cpp:func:`simgrid_load_deployment`. - + .. example-tab:: examples/python/actor-create/actor-create_d.xml - + The following file is used in both C++ and Python. - **React to the end of actors:** You can attach callbacks to the end of @@ -74,7 +74,7 @@ Starting and Stopping Actors actors. .. tabs:: - + .. example-tab:: examples/cpp/actor-exiting/s4u-actor-exiting.cpp This example shows how to attach a callback to: @@ -85,7 +85,7 @@ Starting and Stopping Actors .. example-tab:: examples/c/actor-exiting/actor-exiting.c - This example shows how to attach a callback to the end of a specific actor with + This example shows how to attach a callback to the end of a specific actor with :cpp:func:`sg_actor_on_exit()`. - **Kill actors:** @@ -132,7 +132,7 @@ Starting and Stopping Actors Some actors may be intended to simulate daemons that run in the background. This example shows how to transform a regular actor into a daemon that will be automatically killed once the simulation is over. - + .. tabs:: .. example-tab:: examples/cpp/actor-daemon/s4u-actor-daemon.cpp @@ -151,7 +151,7 @@ Starting and Stopping Actors The stack size can be specified by default on the command line, globally by changing the configuration with :cpp:func:`simgrid::s4u::Engine::set_config`, or for a specific actor using :cpp:func:`simgrid::s4u::Actor::set_stacksize` before its start. - + .. tabs:: .. example-tab:: examples/cpp/actor-stacksize/s4u-actor-stacksize.cpp @@ -165,7 +165,7 @@ See also the examples on :ref:`inter-actors communications ` and the ones on :ref:`classical synchronization objects `. - - **Suspend and Resume actors:** + - **Suspend and Resume actors:** Actors can be suspended and resumed during their executions. .. tabs:: @@ -184,7 +184,7 @@ synchronization objects `. .. example-tab:: examples/c/actor-suspend/actor-suspend.c - See also :cpp:func:`sg_actor_suspend()`, :cpp:func:`sg_actor_resume()`, and + See also :cpp:func:`sg_actor_suspend()`, :cpp:func:`sg_actor_resume()`, and :cpp:func:`sg_actor_is_suspended()`. - **Migrating Actors:** @@ -286,7 +286,7 @@ Communications on the Network - **Basic communications:** This simple example just sends one message back and forth. - The tesh file laying in the directory shows how to start the simulator binary, highlighting how to pass options to + The tesh file laying in the directory shows how to start the simulator binary, highlighting how to pass options to the simulators (as detailed in Section :ref:`options`). .. tabs:: @@ -299,7 +299,7 @@ Communications on the Network - **Basic asynchronous communications:** Illustrates how to have non-blocking communications, that are communications running in the background leaving the process free - to do something else during their completion. + to do something else during their completion. .. tabs:: @@ -329,7 +329,7 @@ Communications on the Network progression of a given communication for a while and then unblock it. ``is_suspended()`` can be used to retrieve whether the activity is currently blocked or not. - + .. tabs:: .. example-tab:: examples/cpp/comm-suspend/s4u-comm-suspend.cpp @@ -338,11 +338,11 @@ Communications on the Network :cpp:func:`simgrid::s4u::Activity::resume()` and :cpp:func:`simgrid::s4u::Activity::is_suspended()`. - + - **Waiting for all communications in a set:** The ``wait_all()`` function is useful when you want to block until - all activities in a given set have been completed. - + all activities in a given set have been completed. + .. tabs:: .. example-tab:: examples/cpp/comm-waitall/s4u-comm-waitall.cpp @@ -361,7 +361,7 @@ Communications on the Network The ``wait_any()`` function is useful when you want to block until one activity of the set completes, no matter which terminates first. - + .. tabs:: .. example-tab:: examples/cpp/comm-waitany/s4u-comm-waitany.cpp @@ -371,11 +371,11 @@ Communications on the Network .. example-tab:: examples/python/comm-waitany/comm-waitany.py See also :py:func:`simgrid.Comm.wait_any()`. - + .. example-tab:: examples/c/comm-waitany/comm-waitany.c See also :cpp:func:`sg_comm_wait_any`. - + .. _s4u_ex_execution: Executions on the CPU @@ -421,7 +421,7 @@ Executions on the CPU :cpp:func:`simgrid::s4u::Activity::cancel()`. .. example-tab:: examples/python/exec-async/exec-async.py - + See also :py:func:`simgrid.this_actor::exec_init()`, :py:func:`simgrid.Activity::start()`, :py:func:`simgrid.Activity.wait()`, @@ -429,7 +429,7 @@ Executions on the CPU :py:func:`simgrid.Exec.get_remaining_ratio()`, :py:func:`simgrid.this_actor.exec_async()` and :py:func:`simgrid.Activity.cancel()`. - + .. example-tab:: examples/c/exec-async/exec-async.c See also :cpp:func:`sg_actor_exec_init()`, @@ -439,7 +439,7 @@ Executions on the CPU :cpp:func:`sg_exec_get_remaining_ratio()`, :cpp:func:`sg_actor_exec_async()` and :cpp:func:`sg_exec_cancel()`, - + - **Remote execution:** You can start executions on remote hosts, or even change the host on which they occur during their execution. @@ -463,7 +463,7 @@ Executions on the CPU computational kernels that span over several machines, such as a PDGEM and the other ScaLAPACK routines. Note that this only works with the "ptask_L07" host model (``--cfg=host/model:ptask_L07``). - + This example demonstrates several kinds of parallel tasks: regular ones, communication-only (without computation), computation-only (without communication), synchronization-only (neither @@ -474,7 +474,7 @@ Executions on the CPU .. tabs:: .. example-tab:: examples/cpp/exec-ptask/s4u-exec-ptask.cpp - + See also :cpp:func:`simgrid::s4u::this_actor::parallel_execute()`. - **Using Pstates on a host:** @@ -534,7 +534,7 @@ result in short reads and short writes, as in reality. .. example-tab:: examples/cpp/io-file-system/s4u-io-file-system.cpp - **Remote I/O:** - I/O operations on files can also be done remotely, + I/O operations on files can also be done remotely, i.e. when the accessed disk is not mounted on the caller's host. .. tabs:: @@ -666,7 +666,7 @@ Interacting with the Platform .. example-tab:: examples/cpp/platform-profile/s4u-platform-profile.cpp - .. group-tab:: XML + .. group-tab:: XML .. showfile:: examples/platforms/small_platform_profile.xml :language: xml @@ -699,7 +699,7 @@ Energy Simulation .. showfile:: examples/platforms/wifi_energy.xml :language: xml - - **Consumption due to the CPU:** + - **Consumption due to the CPU:** This example shows how to retrieve the amount of energy consumed by the CPU during computations, and the impact of the pstate. @@ -740,7 +740,7 @@ Tracing and Visualizing ======================= Tracing can be activated by various configuration options which -are illustrated in these examples. See also the +are illustrated in these examples. See also the :ref:`full list of options related to tracing `. It is interesting to run the process-create example with the following @@ -838,7 +838,7 @@ than the previous examples. .. example-tab:: examples/c/app-token-ring/app-token-ring.c - **Master Workers:** - Another good old example, where one Master process has a bunch of tasks to dispatch to a set of several Worker + Another good old example, where one Master process has a bunch of tasks to dispatch to a set of several Worker processes. .. tabs:: @@ -861,11 +861,11 @@ than the previous examples. .. showfile:: examples/c/app-masterworker/app-masterworker.c :language: cpp - + Data diffusion -------------- - - **Bit Torrent:** + - **Bit Torrent:** Classical protocol for Peer-to-Peer data diffusion. .. tabs:: @@ -892,7 +892,7 @@ Data diffusion .. showfile:: examples/c/app-bittorrent/tracker.c :language: cpp - - **Chained Send:** + - **Chained Send:** Data broadcast over a ring of processes. .. tabs:: @@ -913,7 +913,7 @@ Data diffusion Distributed Hash Tables (DHT) ----------------------------- - - **Chord Protocol** + - **Chord Protocol** One of the most famous DHT protocol. .. tabs:: @@ -994,8 +994,8 @@ Model-Related Examples This simple ping-pong example demonstrates how to use the bindings to the Network Simulator. The most interesting is probably not the C++ files since they are unchanged from the other simulations, but the associated files, - such as the platform file to see how to declare a platform to be used - with the ns-3 bindings of SimGrid and the tesh file to see how to + such as the platform file to see how to declare a platform to be used + with the ns-3 bindings of SimGrid and the tesh file to see how to start a simulation in these settings. .. tabs:: @@ -1008,20 +1008,20 @@ Model-Related Examples .. showfile:: examples/platforms/small_platform_one_link_routes.xml :language: xml - + - **wifi links** - + This demonstrates how to declare a wifi zone in your platform and how to use it in your simulation. For that, you should have a link whose sharing policy is set to `WIFI`. Such links can have more than one bandwidth value (separated by commas), corresponding to the several SNR level of your wifi link. - + In this case, SimGrid automatically switches to validated performance models of wifi networks, where the time is shared between users instead of the bandwidth for wired links (the corresponding publication is currently being written). - + If your wifi link provides more than one SNR level, you can switch the level of a given host using :cpp:func:`simgrid::s4u::Link::set_host_wifi_rate`. By default, diff --git a/examples/deprecated/java/cloud/migration/README b/examples/deprecated/java/cloud/migration/README index 4d9d10a5d4..b346b59326 100644 --- a/examples/deprecated/java/cloud/migration/README +++ b/examples/deprecated/java/cloud/migration/README @@ -1,8 +1,8 @@ There are two tests: -- The first one aims at validating the migration in presence of consolidated VMs +- The first one aims at validating the migration in presence of consolidated VMs - The second one aims at validating the robustness of the migration process (the SRC node or the DST node are turned off during the migration process) -To switch between the first and the second tests, you should instrument Main.java (sorry for that :( ) +To switch between the first and the second tests, you should instrument Main.java (sorry for that :( ) Adsein - Thu Oct 9 18:25:39 CEST 2014 UPDATE: the second test was never used (dit it ever work?), and was removed 4 years later diff --git a/examples/smpi/NAS/README.install b/examples/smpi/NAS/README.install index e999d296e2..56b210a2bd 100644 --- a/examples/smpi/NAS/README.install +++ b/examples/smpi/NAS/README.install @@ -2,13 +2,13 @@ Some explanations on the MPI implementation of a subset of NPB 3.3 (NPB3.3-MPI) ---------------------------------------------------------------------- NPB-MPI is a sample MPI implementation based on NPB2.4 and NPB3.0-SER. -This subset contains three of the original benchmarks: one in Fortran: EP; +This subset contains three of the original benchmarks: one in Fortran: EP; one in C: IS, as well as the DT benchmark, written in C, introduced in NPB3.2-MPI. 1. Compilation Before compilation, one needs to check the configuration file - 'make.def' in the config directory and modify the file if necessary. + 'make.def' in the config directory and modify the file if necessary. make NPROCS= CLASS= \ [SUBTYPE=] [VERSION=VEC] @@ -19,12 +19,12 @@ one in C: IS, as well as the DT benchmark, written in C, introduced in NPB3.2-MP Class E is not available for IS and DT. - Class D for IS (Integer Sort) requires a compiler/system that - supports the "long" type in C to be 64-bit. - + Class D for IS (Integer Sort) requires a compiler/system that + supports the "long" type in C to be 64-bit. + 2. Execution The executable is named .. - The executable is placed in the bin subdirectory (or in the directory - BINDIR specified in make.def, if you've defined it). The method for + The executable is placed in the bin subdirectory (or in the directory + BINDIR specified in make.def, if you've defined it). The method for running the MPI program depends on your local system. diff --git a/examples/smpi/replay_multiple/README b/examples/smpi/replay_multiple/README index 5d4b8fd1fd..7d7ed3f67e 100644 --- a/examples/smpi/replay_multiple/README +++ b/examples/smpi/replay_multiple/README @@ -12,17 +12,17 @@ example : 2 smpi_replay.txt 32 125000000000 -This launches an instance "2" that will replay file smpi_replay.txt with 32 processes, and each one of these processes +This launches an instance "2" that will replay file smpi_replay.txt with 32 processes, and each one of these processes will sleep for 125000000000 flops before the run. -In order to be replayed, a deployment file must be generatedfrom this description file, and from the intended platform -file and hostfiles. The script generate_multiple_deployment.sh can be used as such : +In order to be replayed, a deployment file must be generatedfrom this description file, and from the intended platform +file and hostfiles. The script generate_multiple_deployment.sh can be used as such : ./generate_multiple_deployment.sh -platform platform_file.xml -hostfile hostfile description_file deployment.xml The output deployment file will be written in deployment.xml -Please not that the deployment will use the hostfile in order, placing processes of the first instance using the first +Please not that the deployment will use the hostfile in order, placing processes of the first instance using the first node, and the ones of the following instances on the following nodes. The actual replay can now be launched, using classic options for SMPI diff --git a/src/xbt/mmalloc/mmalloc.texi b/src/xbt/mmalloc/mmalloc.texi index 61d957221f..0669995cf0 100644 --- a/src/xbt/mmalloc/mmalloc.texi +++ b/src/xbt/mmalloc/mmalloc.texi @@ -240,7 +240,7 @@ Given an @code{mmalloc} descriptor @var{md} and a pointer to memory previously allocated by @code{mmalloc} in @var{ptr}, reallocate the memory to be @var{size} bytes long, possibly moving the existing contents of memory if necessary. - + @item void *mvalloc (void *@var{md}, size_t @var{size}); Like @code{mmalloc} but the resulting memory is aligned on a page boundary.