Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Guillaume Fraux
    @Luthaf
    Which is why it covers both =)
    It is still a WIP because I did not get the Ewald MC NPT tests to pass, but from what I remember this was working for NPT simulations of rigid molecules with MC.
    I have a local branch covering more fixes to Ewald, but it is not there yet.
    In the meantime, I'll be happy to discuss the solution / framework I used to get the number of simulated degrees of freedom from the propagator
    I tried to get something that could be expanded to future use-cases, such as algorithms for rigid molecules MD (SHAKE, ...)
    Let me know if the code is understandable, I'll be happy to add more documentation if this is needed
    Gernot Bauer
    @g-bauer

    I have a local branch covering more fixes to Ewald, but it is not there yet.

    Are those fixes concerning bugs in the current implementation? I'll have some time this weekend to do some NPT runs of SPC.

    Guillaume Fraux
    @Luthaf
    Yep! Basically on the reciprocal space part, a lof of k-points where missing (this is entirely my fault, I tried to cut corners with symmetry that does not exist ...)
    I am currently running some more tests locally with MC simulations of NaCl, and then I'll send a PR
    But for SPC I think we will need to have both #225 and these fixes
    Gernot Bauer
    @g-bauer
    Ok! Looking forward to it. Do you know why it passed the tests for SPC NIST configurations?
    Guillaume Fraux
    @Luthaf
    Mainly because we used both a big cutoff in real space and a big cutoff in reciprocal space, which make the reciprocal part of the energy negligible wrt the real space part.
    But changing the values tu use and small real-space cutoff make the error appear!
    Gernot Bauer
    @g-bauer
    Mhm that's why we had to use smaller tolerances for the errors I guess?!
    Guillaume Fraux
    @Luthaf
    what do you mean ?
    Gernot Bauer
    @g-bauer
    If I remember correctly, when implementing the tests for Ewald (versus NIST), we found that for small cutoffs the energies were a bit off. AFAIK we reduced the tolerance for the tests to pass. This could stem from the bugs you found.
    Guillaume Fraux
    @Luthaf
    Oh, I did not remeber that ... I'll give it a look!
    Gernot Bauer
    @g-bauer
    See here: lumol-org/lumol#75
    Not sure if that's the reason. We used different alphas. I'm not sure either. We should check the tests for the new implementation :)
    Guillaume Fraux
    @Luthaf
    Nowadays we have the same alpha values: https://github.com/lumol-org/lumol/blob/383d4b60fb8145264f4ea42107e8ee89e1c1314b/tests/nist-spce.rs#L72
    But it is worth checking it more carefully!
    Gernot Bauer
    @g-bauer
    :thumbsup:
    Guillaume Fraux
    @Luthaf
    Hey @g-bauer, would you have some time to give a look to #240 and #241 ? Else I can merge them directly, as they are small PR with tests :smiley:
    Gernot Bauer
    @g-bauer
    I'll check #241 tomorrow!
    Gernot Bauer
    @g-bauer
    Seems like you are able to reproduce the LAMMPS data for SPC using Ewald! Thats awesome!
    Guillaume Fraux
    @Luthaf
    Yep, that nice ! But I still have the same issue with MC NPT. I'll check tomorrow if I can find what's wrong with either the Resize move or the energy cache
    and thanks for taking the time to merge #240!
    I rebased #241 on top of master, it is a pretty straightforward PR. I think the main change is the switch from .zip() methods to a soa_zip! macro in soa-derive
    Guillaume Fraux
    @Luthaf
    I think I found the remaining issue with #237: the default value for alpha was wrong, creating a big error specifically in the case of periodic systems such as the crystal I was using for testing
    Gernot Bauer
    @g-bauer
    You mean also w.r.t the NPT simulations?
    Guillaume Fraux
    @Luthaf
    yes :smile:
    Gernot Bauer
    @g-bauer
    That's nice!
    Garrett Jepson
    @gjepson
    Hello, I'm trying to use lumol via a Rust program. Could you point me towards the relevant documentation?
    Gernot Bauer
    @g-bauer
    Hey @gjepson, could you specify what you want to do? Do you mean using lumol as library within a Rust program? Then, I'd recommend taking a look at the examples here. The functions used within the examples are documented within the API documentation, which you can find here. Does that help?
    Guillaume Fraux
    @Luthaf
    Also, if you are willing to use the input system, you can follow the code in bin/lumol.rs for the lumol binary. If you don't use the input system, you might want to setup a logging backend in your own main to get the warning/error messages.
    Garrett Jepson
    @gjepson
    Yes, using lumol as a library. Thank you for those. One thing: whenever I try to run 'lumol argon.rs' from 'lumol/examples', I get the error message: '[error] invalid input file: unexpected character found: / at line 1'
    Gernot Bauer
    @g-bauer
    Can you try to run cargo run --example argon --release (from within the lumol directory)
    The lumol command expects an input toml file. The .rs files in the examples folder show how to use lumol as a library. You don't need an input file there if you specify everything within the source files.
    But you have to compile them before they can be ran. The cargo command above does that for you. Let me know if that works!
    (FYI the error message you got is because lumol expects a toml as input and can't parse the comment of the .rs file)
    Garrett Jepson
    @gjepson
    Gotcha, that worked well, thanks!
    Gernot Bauer
    @g-bauer
    :thumbsup:
    A Dinesh
    @dineshadepu
    Hello all. I am implementing a similar package for simulating Discrete element method. I just have a question regarding parallel functionality. I implemented the serial version. I need it to make it parallel. I just need some resources so that I can make the code parallel. I need to make the for loops parallel. Can you please help on how to implement parallel for loops in rust?
    Serial version is https://github.com/dineshadepu/demsph/blob/master/src/physics/dem/equations.rs#L100
    I want to make those two for loops parallel
    Is it at least doable?
    Guillaume Fraux
    @Luthaf
    Hey @dineshadepu, this has nothing to do with lumol, so I'd rather keep the discussion about this out of this forum. You'll get more answers on http://users.rust-lang.org/. Long story short, we are using rayon, and it is amazing!
    tabedzki
    @tabedzki
    Hi all, I noticed that lumol hasn't had a commit in a while. Is the project still maintained?
    Guillaume Fraux
    @Luthaf
    Hey @tabedzki, thanks for checking out! I haven't have the opportunity to work on lumol in a while; and my current line of work and funding as a postdoc does not include classical molecular simulation, so you are right that the project is a bit stale right now. However, I am still interested to come back to it when I find some time! I would still be very happy to collaborate and merge contributions though!
    tabedzki
    @tabedzki
    Ahhh, ok. I haven't looked into Lumol much, I was just looking into how much the program was being worked on. I don't know if you have nay data, but how does this software perform against something like LAMMPS or GROMACS?