Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    rogerjiang01
    @rogerjiang01
    Thanks for the reply. I increase the value of "mesh_side_length", and it get a better performance on computation. Is it cause by reducing the accuracy of the gravity?
    Josh Borrow
    @JBorrow
    Can you be more specific? What values?
    rogerjiang01
    @rogerjiang01
    I replace the value of "mesh_side_length" by 320 which the default is 128 in the eagle_50.yml file. Does it reduce the accuracy of the gravity, so I get a better performance?
    Matthieu Schaller
    @MatthieuSchaller
    This is a complicated question. It does affect the speed but also the accuracy of the solver
    But in complicated ways.
    If the solver was perfect, then that parameter would not have any impact as we could smoothly transition from using the mesh or the tree for the gravity
    That is not true in SWIFT and for that matter in any Tree-PM code (e.g. Gadget)
    There is an error introduced at the scale of the mesh cell size
    Depending on what you want to simulate, this may or may not be something you care about
    rogerjiang01
    @rogerjiang01
    Got it! Thanks for your answer.
    rogerjiang01
    @rogerjiang01
    Hi, all. After I read the several papers in SWIFT official website, I have a few questions.
    First, I got the dependency graph after I run EAGLE_50 task. I'm wondering about the meaning of numbers on the graph. The graph is similar to the figure which is about the dependency and conflict on the paper, but what can I tell from the numbers?
    dependency_graph8-50-128.png
    Then, I get the output log from SWIFT for each run. However, I would like to know what does the time-step mean? Does it indicate that it runs through a complete process (from drifting to kicking) once?
    Thanks~
    Matthieu Schaller
    @MatthieuSchaller
    hi
    The numbers on the task graph correspond to the number of such links present in this run
    So here for instance, you have 125000 kick2 tasks each unlocking a timestep task
    A time-step is indeed a full run through the task graph
    But note that only the active particles are updated and to do we only activate the tasks that will act upon cells that contain active particles
    rogerjiang01
    @rogerjiang01
    Thanks for your reply. So, can I say the quantity of the specific task is the sum of the number on the links?
    For instance, the amount of the timestep task is 125000+376776 according to the graph above.
    Matthieu Schaller
    @MatthieuSchaller
    No
    Some task can unlock multiple other ones
    In this case you likely have 125000 time-step tasks
    125000 kick1
    and 376776 send_ti
    rogerjiang01
    @rogerjiang01
    Got it! Thanks!
    Yonatan
    @yonatansmn
    Hi. I'm working on planetary impacts, and I'm having difficulties fully utilizing parallel computations, as Metis partition keeps failing if I try to run on more than 4 cores. My simulations consits of 1e6,1e7 particles.
    Also, running on 4 cores works about as fast as a non-parallel simulation.
    I'm working on version 0.8.5.
    Matthieu Schaller
    @MatthieuSchaller
    for so few cores, you don't need the MPI version. You should use the swift executable and set the number of threads via the -t runtime parameter.
    Yonatan
    @yonatansmn
    I want to run on more than 4 cores, but Metis keeps failing
    Yonatan
    @yonatansmn
    Matthieu do you have suggestions? I think the problem is regions not present in partition
    Matthieu Schaller
    @MatthieuSchaller
    How many cores does your node have?
    Also, you will have to give more details about what fails. If you are compiling without metis, you can still use MPI. In that case, you will be using a regular partition that usually works quite well anyway.
    Yonatan
    @yonatansmn

    There are 12-24 nodes per core. My configuration command is:
    ./configure CC=/usr/local/gcc/gcc-6.4.0/bin/gcc --prefix=/home/shimoni/apps/swift0.8.5 --with-parmetis=/home/shimoni/apps/parmetis-4.0.3/ --with-tbbmalloc=/usr/local/intel/2017/tbb/lib/intel64/gcc4.7 --with-fftw=/home/shimoni/apps/fftw-3.3.8 --with-equation-of-state=planetary --with-hydro=planetary.

    According to the summary, Parmetis is enabled and Metis is not.

    I recieve the following message:
    check_complete: Region # not present in partition

    Followed by:
    partition_initial_partition: METIS initial partition failed, using a vectorised partition

    Yonatan
    @yonatansmn
    And I run on 12 MPI ranks
    Matthieu Schaller
    @MatthieuSchaller
    can you show me how you run swift?
    Yonatan
    @yonatansmn
    mpirun -np 12 /$HOME/apps/swift0.8.5/bin/swift_mpi -t 24 -v 1 -asG YML/jobname.yml
    Matthieu Schaller
    @MatthieuSchaller
    so you are using 288 cores for a job with 10M particles? that's overkill. And that's what metis tells you. it can't find a domain decomposition that makes sense in your case.
    Matthieu Schaller
    @MatthieuSchaller
    the code won't crash but it will not use all the nodes
    Yonatan
    @yonatansmn
    So the answer is to lower the number of MPI ranks?
    Matthieu Schaller
    @MatthieuSchaller
    That is what the code does. It decides to not give any particle to some of the nodes as it would be inefficient to split the domain more finely
    Yonatan
    @yonatansmn
    That is the vectorised partition?
    Matthieu Schaller
    @MatthieuSchaller
    no
    If you use grid you get a grid
    if not then you get domains of random shape
    the different partition mechanisms are different way of deciding hot to cut things efficiently
    If no such cut can be done with all N nodes, then the code tries with fewer nodes
    and decides to leave some nodes empty as it will be faster