spackbot-app[bot] commented on issue spack/spack#35345.
…
wdconinc commented on issue spack/spack#35345.
@spackbot fix style …
JoseAgustin commented on issue spack/spack#31612.
In spack version 0.20.0. I solved by: …
v-dobrev commented on issue mfem/mfem#3447.
This is a good catch. The assumption I made in https://github.com/mfem/mfem/pull/3349#discussion_r1039488255 was that all overrides of FiniteElementCollection::FiniteElementForGeometry will return NULL when there is no specific FE associated with the given Geometry::Type. However, this convention is not followed by all FiniteElementCollection sub-classes and, instead, some of them generate an error.
…
serikkehva commented on issue spack/spack#35281.
I don’t understands the first sentence. Bazel is in the dependency list of py-horovod and needs to be installed if you specify tf and keras frameworks. …
srekolam commented on issue spack/spack#33610.
@tldahlgren @renjithravindrankannath , can i get this rerviwed and merged. Been in review for a very longtime. …
prj- commented on issue hypre-space/hypre#829.
Thanks for the PR. For reference, here is the corresponding PETSc MR: https://gitlab.com/petsc/petsc/-/merge_requests/6022….
grondo commented on issue flux-framework/flux-sched#1001.
A good test may be to try reloading sched-fluxion-qmanager and sched-fluxion-resource to see if the problem goes away. However, we may want to collect as much information from the affected system before doing that to better understand the problem. cc: @trws and @milroy to see if they have any other ideas….
codecov[bot] commented on issue flux-framework/flux-core#4883.
# Codecov Report…
chu11 commented on issue flux-framework/flux-core#4883.
oops, re-pushed, a “top_builddir” should have been “top_srcdir”…
tbennun commented on issue LLNL/lbann#2178.
@bvanessen done, also cleaned up the PR….
pazner commented on issue mfem/mfem#3442.
1. The Dockerfile to build the container is here …
milroy commented on issue flux-framework/flux-sched#997.
LGTM @grondo! Setting MWP….
garlick commented on issue flux-framework/flux-core#4881.
Sorry yes that was clear! I had pushed an intermediate step and hadn’t context switched back to this PR to finish the job yet….
tlorentz77 commented on issue LLNL/axom#982.
Thanks very much. @kennyweiss …
gzagaris commented on issue LLNL/Umpire#799.
Hey @davidbeckingsale – just got bitten by this again. …
trws commented on issue flux-framework/flux-sched#991.
If that isn’t sufficient I’d be somewhat interested to know why not, because it seems like the kind of problem we could solve with an index if it’s not currently feasible. Do we currently require the full path keys?…
lucpeterson commented on issue LLNL/merlin#400.
Do the changes to the makefile necessitate a change to the isort version? Do we need to change any requirements?…
koning commented on issue LLNL/merlin#400.
Two users have been unable to run the tutorial example (openfoam_no_docker) because of the openfoam access issue….
bvanessen commented on issue LLNL/lbann#2178.
@tbennun Please add an entry to the ReleaseNotes.txt file…
cyrush commented on issue LLNL/conduit#1075.
@kennyweiss glad that helped and thanks for confirming! …
kennyweiss commented on issue LLNL/conduit#1075.
Update: I built axom against conduit@0.8.6 and verified that this bug has been resolved.
…
jaelynlitz commented on issue LLNL/Umpire#800.
Thanks for the suggestion @davidbeckingsale. I tried adding the --gcc-toolchain flag to our spack.yaml (attached), but it seems as though the flag was not picked up. Maybe my syntax is off.. The spack build output is also attached - it’s picking up gcc10.2.0 and hipcc as the compilers, but still finding the 4.8.5 include dir.
…
davidbeckingsale commented on issue LLNL/Umpire#800.
Sorry I missed this. It looks like a system configuration problem. Your build is pulling in standard library headers from GCC 4.8.5: /usr/lib/gcc/x86_64-redhat-linux/4.8.5.
…
jfavre commented on issue Alpine-DAV/ascent#1079.
This issue seems to be fixed now with v0.9.0 …
lindstro commented on issue LLNL/zfp#199.
From the discussion above, we do expect issues when using zfp with TBB if the code is not compiled with OpenMP enabled. Do the segmentation faults persist if you compile with -fopenmp? Given that ThreadSanitizer gives false positives for the most basic OpenMP example, I think we cannot rely on it to diagnose data races. To make further progress, I would need a complete–but minimal–code example that invokes provably erroneous behavior….
aavbsouza commented on issue LLNL/zfp#199.
Hello @lindstro the original motivation for the issue was a segmentation fault on a code when running in parallel (with oneapi::tbb), the snippet used on this thread is based on a pattern that appear on this code. Others sections of this same code I was able to run with thread sanitize enabled without generating false positives. However the section in that code that is similar to the above snippet when executed with the thread sanitize enabled presents the same kind of errors show on this thread. And the problem only manifests if the parallelism is enabled. …
doutriaux1 commented on issue LLNL/maestrowf#412.
@FrankD412 do you want to remove 3.7 from the test section as well? Or do we want it for testing?…
jiuxiaocloud commented on issue LLNL/sundials#251.
## Well, oenapi-src/oneMKL for cuda backend has been test on my Ampere-GPU(sm_86) …
gardner48 commented on issue LLNL/sundials#251.
At present the SYCL NVector only supports targeting GPUs and has only been tested with Intel GPUs. Targeting GPUs from other vendors is possible using SYCL and oneMKL but is untested as the current focus is Intel GPU support. Any feedback on using the SYCL vector and oneMKL solver interface on other devices is welcome.
…
white238 commented on issue LLNL/scr#529.
Most projects don’t bother to build both static and shared libraries in the same configuration. Some do though. It is really a matter of preference. What you have is fine. Some people will want static, some will want shared, but most won’t care. As long as it’s documented that’s fine. If you are going to build both, it is nice to have a way to grab the static vs shared library….
adayton1 commented on issue LLNL/Umpire#809.
Thanks! I didn’t have a specific case (we don’t build the examples in Umpire), but I encountered this when grepping the code for features that were removed in c++17….
mcfadden8 commented on issue LLNL/scr#529.
I’ve been thinking about this and have asked around a little. I really don’t have a great answer to offer other than I think that there should be two entirely different build/installation directories for shared and static libraries with XXXConfig.cmake files that are different depending upon what kind (static or dynamic) of library is being built …
adammoody commented on issue LLNL/scr#529.
@white238 and @mcfadden8 , last week I merged in support for an scrConfig.cmake file that gets installed with SCR and has references to SCR dependencies. This should enable a CMake application to just list scr::scr.
…
mrowan137 commented on issue LLNL/CARE#211.
Oh yeah sorry about that, I did a cleanup of the commit history. I had goofy mistake in one of the commits. If there’s no preference to have a clean commit history, I will avoid ‘rewriting history’ in the future!…
grondo commented on issue hpc/Spindle#50.
@mplegendre Let me know if there is anything else needed here…
nkeilbart commented on issue LLNL/merlin-spellbook#40.
I did a lint check on the files I changed. Also, I added another feature we thought would be useful which is to repeat the samples being generated in case multiple runs are wanted. Additionally, if you’d like each sample to have a different seed the user can specify which column is the seed column. Each repeated sample will then have the same seed. For example, …
slabasan commented on issue LLNL/spotbe#19.
SPOT no longer using this implementation for reading in hatchet files (currently using SpotDB). …
adrienbernede commented on issue LLNL/CHAI#218.
re: …
lucpeterson commented on issue LLNL/merlin-spellbook#40.
Can we run a lint fix and get some tests that this works before we merge it in?…
ryannova commented on issue LLNL/merlin#371.
Addressed in #369…
ilumsden commented on issue LLNL/hatchet#72.
This PR is now ready for review. However, it should not be merged until after #73 so that we can make sure it passes CI….
artv3 commented on issue LLNL/CHAI#219.
@adrienbernede @davidbeckingsale , I’m a bit confused about the failures. It looks like the gitlab builds use a different version of RAJA than that I pointed at. …
jwhite242 commented on issue LLNL/maestrowf#408.
So in that case, what is setting those tags? Tags can be overwritten silently, which seems ripe for trouble vs keeping it in the toml file directly. Also, when you build a wheel with something like that what does the name get mangled into for installing? didn’t think pep440 supported the ‘-
kcathey commented on issue LLNL/maestrowf#408.
I’m for bumpver and with a bump to an alpha version after cutting a release. Then in an MR to main when working a release in that branch cut to the release candidate tag, if desired an rc build could get pushed to pypi….
