I think I need to use mpi, mpich, or mkl, but I'm not sure how to set these up properly. I'm following this guide : http://www.fisica.uniud.it/~giannozz/QE-Tutorial/installation.html
also section 2.9.2.3 seemed relevant : https://www.quantum-espresso.org/Doc/user_guide/node16.html#SECTION00039220000000000000
Related
I am trying to use some open-source CFD code, and it uses PETSC and some other libraries, so I installed them. But when I try to compile program useing 'make', it seems like libraries are not properly linked with makefile
It seems like petsc isn't properly linked, but I can't know why...
The problem is that PETSc depends on some more libraries (X11) than the CFD package counted on. It should have a proper configure that figures these out. However, you can get the link line you need using
cd PETSC_DIR; make getlinklibs
which you can then put in LIBFLAG.
When I install Pkg.add("FFTW"), how does Julia link to FFTW? I guess it downloads a pre-compiled version because I didn't give it a path to link my local version and it didn't seem to take long enough to be compiling FFTW from source. Is that correct? If so, is there a way to set Julia to use a locally compiled and optimized version of FFTW? I ask because I have a simulation code with both a Julia and a C++ version, and the C++ one runs about 6-7x faster, even though I think both should be spending most of their time in FFTW calls. So I am wondering if the difference is that the Julia version is using a less well optimized build of FFTW.
Many Julia packages provide prebuilt libraries through the so called JLL. Julia also provides a mechanism to override these artifacts.
In particular, your ~/.julia/artifacts/Overrides.toml will look like
[f5851436-0d7a-5f13-b9de-f02708fd171a]
FFTW = "...."
where .... is the "prefix" where your FFTW is installed, i.e. the directory in which there is the lib/libfftw.... file. You can read more about overriding artifacts of JLL packages at https://juliapackaging.github.io/BinaryBuilder.jl/dev/jll/#Non-dev'ed-JLL-packages
If you happen to find that the slowdown is due to the different library, please do report it to https://github.com/JuliaPackaging/Yggdrasil/
My goal is to connect the open-source CBC solver with Pyomo in Spyder. I am working on a Windows 10 machine and it is not an option for me to use the NEOS server due to company policy.
I have downloaded the binaries from Bintray (https://bintray.com/coin-or/download/Cbc#files) that include a cbc.exe file. However when trying to run it, several errors come up stating that I am missing files (among other libbz2-1.dll and zlib1.dll). I do not know much about linux or software development but after a lot of time on google I understand that these are used for unpacking data among other things. I found all files except zlib1.dll in a developer chat on the same subject and zlib1.dll I found on another page. However when running I now get the error: “The application was unable to start correctly (0xc000007b).
I have also tried downloading MSYS2 MinGW and followed instructions from CBC. I don’t know if I require this or if it is only for developers.
Can anyone tell me what to do? I suspect other people than myself want to use CBC in Pyomo as an alternative to GLPK.
If you already have the .exe file, make sure it is in your current working folder (set as the working directory in Spyder, simply opening your file is not enough) and call it using the SolveFactory function:
opt = SolverFactory("cbc.exe")
results = opt.solve(model)
It works for me.
You will find some general information here where i outlined some approaches.
While this was targeted at Clp, it also applies to Cbc.
It's a bit strange as i observed too, that some libs are not statically linked (zlib) while it's certainly doable. But as mentioned in the thread, this should not be the case anymore (see the restriction about which files are fully statically linked) and therefore your observation is strange (and you did not say, which file you downloaded).
So i would trying one of the following (in this order):
Try again with your source, but stick to the master-versions (see first link) as the maintainer only guaranteed fully-static builds for those!
Use the builds from AMPL
(tested and works for me; generally recommended in terms of quality/stability of builds)
Use the builds from coin-or/pulp, another modelling-tool for python
(tested and works for me)
Compile from source using mingw64
(Use any build and provide some external dll of zlib and co -> hard to debug)
Of course i completely ignored other potential issues:
license-stuff (what's part of those builds)
not sure if a company can afford to use binaries not build themself in regards to legal stuff
version-compatibility with python
does every version of Cbc work
cbc version + configuration
modern version
compiled with multi-threading
...
I downloaded the latest source code of Opensplice DDS from https://github.com/ADLINK-IST/opensplice and tried to build it by following its instructions (source setenv, source ./configure, then make ..) in my Cygwin 64 bit.
The build (make command) appeared to be completed, but a number of modules such as dcpsisocpp2, durability, spliced didn't get built (I can't find dcpsisocpp2.dll, etc).
I wonder if anyone who is familar with Opensplice's makefile system can direct me to solve the problem.
You should identify you are going to use community or enterprise version.
It seems the community version doesn't have spliced and durability services. Also, dcpsisocpp2 use C++03 which is a very old C++ standard, that when you use C++11 or C++14 writing your application, you might get some warning or error and spend lots of time fixing compile problems.
Try to use dcpssacpp which follows the C++11 standard.
I know we can always use eselect to change the compiler version. My question is that possible to bind different version to different users. For example, I would like root to use stable version for sure. and meanwhile, I would like my normal user to use some edge-cutting version.
I expect some clean solution instead of switch manually by using eselect
Thanks
I really hope you're not using eselect for this. eselect-compiler was killed off years ago because it was experimental and had many problems. gcc-config is what you should be using. Unfortunately it doesn't have per-user support like we have for Java. You can always call the specific version explicitly (e.g. gcc-4.6.2 instead of just gcc). If you're building software with autotools then you can do it with...
CC=gcc-4.6.2 ./configure
make
You can use gcc-config to print the environment variables necessary to use a specific GCC version. For example, to use gcc-7.2.0 for the remainder of your shell session:
eval "$(gcc-config --print-environ x86_64-pc-linux-gnu-7.2.0)"