mineralscloud / express.jl Goto Github PK

The current implementation is just mktempdir(), which requires users to set the TMPDIR environement variables, etc. (See http://docs.julialang.org/en/v1/base/file/#Base.Filesystem.tempdir) to not occupy system /tmp dir, which is often not owned by users but the system administrators on a supercomputer.

I propose take the control.outdir as prefix, then create a mktempdir() by mktempdir(). Should be easier to set.

Is your feature request related to a problem? Please describe.
I have already added units to EquationsOfState.jl, but the update_alat_press needs units also to find the correct alat parameter.

Describe the solution you'd like
Add a unit conversion step in update_alat_press.

Like what I mentioned in "Make readoutput more extensible?", the current implementations of makeinput, etc., are not so extensible. I am considering making current inner closure out, and outer function in.

Hi,
I'm one of the referees for your paper. I've received the scripts you sent me through the editor and ran them (I'm using julia1.6 to run your code though). I'm then trying to run an eos calculation shown here:

If I run it using xps I get this error:

When trying to run it with a julia script I run into a different error:

Any ideas on how to fix this?

@JuliaRegistrator register()

Phonon.SelfConsistentField depends on the last step results (optimized cells), so it may acquire a variable that takes either a new_structure or output. And Dfpt is even more complicated because it needs input from previous steps. But how to distribute the function on each slice of its arguments? One way is

function f(g, args...; kwargs...)
    map(zip(args...)) do arg
        g(arg...; kwargs...)
    end
end

This is exactly like IterTools.imap.

However, Base.map can do similar things. But it cannot take kwargs, so is IterTools.imap. The most flexible one is the one I wrote above.

The current definitions of Pressures & Volumes support construction from an AbstractVector. This is OK in EOS & phonon workflows, but it is not very handy in the QHA workflow since it requires a lot of temperatures and pressures. So we also need to support config the desired temperatures, volumes, pressures from a simple, step-range like syntax like 1:10:300. The following definition is considered fine:

@option struct Temp4
    values::Union{AbstractVector,String}
    unit::String = "K"
    function Temp4(values, unit)
        if values isa Vector
            return new(values, unit)
        elseif values isa String
            return new(Meta.parse(values) |> eval, unit)
        else
            error("")
        end
    end
end

I'm one of the developers of AtomsBase. I'm SO excited that Express.jl exists, and I'd love to discuss the best way that it could support the AtomsBase interface to further enhance interoperability amongst materials science packages in Julia!

I'd love to set up some time to discuss this, perhaps with some of the other AtomsBase team such as @mfherbst and @jgreener64 – maybe during JuliaCon?

@JuliaRegistrator register()

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

In commit "a975d2aaf7314e3c1cbb82413686e46cee4f374a" I remove all exports in EosFitting.jl & Phonon.jl. But after reading "Development with Interface Packages", maybe I should not do that? Because Express.jl should be an interface package and QuantumESPRESSOExpress.jl, etc., should just implement it? Like

using Express.Phonon: buildworkflow
using QuantumESPRESSOExpress.Phonon

rather than

using QuantumESPRESSOExpress.Phonon: buildworkflow

@JuliaRegistrator register()

Now we have workdir as a parameter and has it checked. But it does not seem to be necessary. The directory where the config file sits should be considered as workdir, as it is currently used by default. Let's see why:

1. The templates are still need to be provided paths, and they are not necessarily relative to workdir.
2. xps command, or using from Julia REPL, has to specify a config file path, and that was supposed could be not in workdir. But now users have to set path for config files, workdirs & templates, that's a lot of complications.
   So I am considering just deprecate the workdir parameter.

@JuliaRegistrator register()

@JuliaRegistrator register()

@JuliaRegistrator register()

@JuliaRegistrator register()