Issue Comment Events

Projects RADIUSS Home

spackbot-app[bot] commented on issue spack/spack#35345.

View Comment

wdconinc commented on issue spack/spack#35345.

@spackbot fix style …

View Comment

JoseAgustin commented on issue spack/spack#31612.

In spack version 0.20.0. I solved by: …

View Comment

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. …

View Comment

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. …

View Comment

srekolam commented on issue spack/spack#33610.

@tldahlgren @renjithravindrankannath , can i get this rerviwed and merged. Been in review for a very longtime. …

View Comment

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….

View Comment

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….

View Comment

codecov[bot] commented on issue flux-framework/flux-core#4883.

# Codecov Report…

View Comment

chu11 commented on issue flux-framework/flux-core#4883.

oops, re-pushed, a “top_builddir” should have been “top_srcdir”…

View Comment

tbennun commented on issue LLNL/lbann#2178.

@bvanessen done, also cleaned up the PR….

View Comment

pazner commented on issue mfem/mfem#3442.

1. The Dockerfile to build the container is here

View Comment

milroy commented on issue flux-framework/flux-sched#997.

LGTM @grondo! Setting MWP….

View Comment

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….

View Comment

tlorentz77 commented on issue LLNL/axom#982.

Thanks very much. @kennyweiss …

View Comment

gzagaris commented on issue LLNL/Umpire#799.

Hey @davidbeckingsale – just got bitten by this again. …

View Comment

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?…

View Comment

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?…

View Comment

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….

View Comment

bvanessen commented on issue LLNL/lbann#2178.

@tbennun Please add an entry to the ReleaseNotes.txt file…

View Comment

cyrush commented on issue LLNL/conduit#1075.

@kennyweiss glad that helped and thanks for confirming! …

View Comment

kennyweiss commented on issue LLNL/conduit#1075.

Update: I built axom against conduit@0.8.6 and verified that this bug has been resolved. …

View Comment

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. …

View Comment

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. …

View Comment

jfavre commented on issue Alpine-DAV/ascent#1079.

This issue seems to be fixed now with v0.9.0 …

View Comment

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….

View Comment

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. …

View Comment

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?…

View Comment

jiuxiaocloud commented on issue LLNL/sundials#251.

## Well, oenapi-src/oneMKL for cuda backend has been test on my Ampere-GPU(sm_86) …

View Comment

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.

View Comment

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….

View Comment

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….

View Comment

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 …

View Comment

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. …

View Comment

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!…

View Comment

grondo commented on issue hpc/Spindle#50.

@mplegendre Let me know if there is anything else needed here…

View Comment

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, …

View Comment

slabasan commented on issue LLNL/spotbe#19.

SPOT no longer using this implementation for reading in hatchet files (currently using SpotDB). …

View Comment

adrienbernede commented on issue LLNL/CHAI#218.

re: …

View Comment

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?…

View Comment

ryannova commented on issue LLNL/merlin#371.

Addressed in #369…

View Comment

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….

View Comment

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. …

View Comment

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 ‘-' suffix on wheels. Is this mainly just the version users would see if they install from source (editable or otherwise)?...</small>

View Comment

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….

View Comment