Chrismarsh commented on issue spack/spack#43002.
As far as I can tell, this package is not installed. …
spackbot-app[bot] commented on issue spack/spack#45393.
…
trws commented on issue flux-framework/flux-core#6128.
The focal docker build has been restored….
rcarson3 commented on issue LLNL/blt#660.
@white238 I’ve recently run into this issue for some of my pure C++ libraries I manage when I moved to newer versions of BLT and my HIP testing of them. Would you be open to accepting a patch for the v0.6.x release branch that fixes this bug by adding a guards around it by something like this in BLTOptions.cmake: …
JustinPrivitera commented on issue visit-dav/visit#19677.
polyhedral mixed case is supported b/c polyhedral mixed case is really just a preprocessing step that creates a new mixed topo; it still hits Brad’s logic down the road….
scheibelp commented on issue spack/spack#43002.
Thanks for trying that, can you try also: …
v-dobrev commented on issue spack/spack#44722.
I left a few comments regarding the changes in the mesa package. I cannot speak about the other changes….
codecov[bot] commented on issue flux-framework/flux-sched#1246.
## Codecov Report…
trws commented on issue flux-framework/flux-sched#1246.
Ok, the build failures should be fixed. As part of that this is now stacked on top of #1256, but should be ready for review….
milroy commented on issue flux-framework/flux-sched#1246.
@trws I noticed the updates and build failures. Should I hold off on a review until everything is green, or should I review this as is?…
codecov[bot] commented on issue flux-framework/flux-core#6149.
## Codecov Report…
gberg617 commented on issue LLNL/axom#1390.
> Fixes #256. …
artv3 commented on issue LLNL/RAJA#1702.
> > This is just testing the mechanics, right? There are no things that actually use/test the fact that the loops are named? …
cyrush commented on issue LLNL/Caliper#388.
That sounds like a good way to move forward. If you have an idea of what minimal string to try I can test a patch on windows. …
daboehme commented on issue LLNL/Caliper#388.
Ouch, okay. Thanks @cyrush for the report. I didn’t realize there’s a limit on string literals. As a short-term workaround we can simply give MSVC a shorter string with only a few of the options (or nothing at all, depending on what the target app needs). I hope the compiler won’t run into this issue if the string is #ifdef‘d out. Most of the options in there aren’t supported on Windows anyway. …
hariharan-devarajan commented on issue LLNL/scr#593.
@CamStan I looked over the documents. My understanding is that the scripts and readme within scripts/python/scrjob are internal and are called by other scripts. Adding those to either user or dev doc seems an overkill.
…
spencer-gre commented on issue LLNL/hatchet#144.
@tpatki …
tpatki commented on issue LLNL/hatchet#101.
Superseded by #144. …
lindstro commented on issue LLNL/zfp#240.
You’ve included a lot of code, e.g., with support for multiple compression modes. It would help us isolate the issue if you could reduce the 1D example to only the essential code being executed. …
Chuan1937 commented on issue LLNL/zfp#240.
I continued to test the decompressed data and found that the data values were all 0。 I don’t know how to solve it, I hope someone can give me some help…
ilumsden commented on issue LLNL/Caliper#576.
In the future, it might be useful to consider embedding archspec-json if more architecture-specific features are added to Caliper….
chu11 commented on issue flux-framework/flux-sched#1253.
oops … wrong place. moving to flux-core…
victorapm commented on issue hypre-space/hypre#1104.
Hi Paul, I will work on these additions. In the meantime, please let me know if you have any issues with our autotools HIP build …
siebrenreker commented on issue LLNL/zfp#238.
Hi @lindstro, would you then also prefer this PR to be targeted to the staging branch?…
davidbeckingsale commented on issue LLNL/blt#341.
Later RAJA releases contain the conditional code in CMakeLists for only adding that flag when appropriate….
vessokolev commented on issue LLNL/blt#341.
> > @rrsettgast - this is a problem with GCC and CUDA 10, fixed in CUDA 11. The correct workaround is to add the flag -Xcompiler -mno-float128 to your CUDA compile flags. We already have the workaround for this in RAJA: https://github.com/LLNL/RAJA/blob/develop/CMakeLists.txt#L92
…
JanLJL commented on issue LLNL/zfp#235.
Hi Peter, …
hmaarrfk commented on issue LLNL/zfp#231.
See #227 or I believe I had a patch: …
jaimergp commented on issue LLNL/zfp#231.
I don’t know why it can’t find the Python.h headers. They are there in include. Those CMake functions are now deprecated so maybe it would be a good idea to upgrade them, but I don’t have the time nor the expertise to dive there, sorry….
nychiang commented on issue LLNL/hiop#651.
> @nychiang I will be reviving this work in another PR using NAERM GitLab. …
cameronrutherford commented on issue LLNL/hiop#651.
@nychiang I will be reviving this work in another PR using NAERM GitLab. …
t20100 commented on issue LLNL/zfp#222.
Same issue when building ZFP as part of hdf5plugin with Visual Studio 2022 17.10.3 (MSVC/14.40.33807): /Ob1 fixes the issue as well….
bgunnar5 commented on issue LLNL/merlin#488.
I had a test fail on a branch of my forked repo for the same reason but I have no idea what’s causing it. I’m going to try removing 3.7 to see if it also happens in other versions when I get the chance…
lucpeterson commented on issue LLNL/merlin#488.
I’m not sure why this is failing. It looks like py 3.7 is dying on package install / pip and is cancelling everything else….
white238 commented on issue LLNL/blt#693.
No problem. Glad it helped. …
drmichaeltcvx commented on issue LLNL/blt#693.
Indeed, after setting set(ENABLE_YAPF OFF CACHE BOOL "") GEOS builds completely.
…
gonsie commented on issue LLNL/scr#459.
This PR is so outdated that I’m closing it rather than figure out how to bring it up to date. We may want to revisit this some day… but not today….
romintomasetti commented on issue LLNL/hatchet#103.
Hi @Julius-Plehn ! Any update on this ? I am using hatchet.GraphFrame.from_timemory, which seems broken. It would be nice to re-enable testing for this reader :wink:…
kathrynmohror commented on issue LLNL/scr#590.
@gonsie Are there user facing interfaces that have changed or been added? If so, then yes…
jithunnair-amd commented on issue LLNL/hatchet#134.
Closing since py3.12 binaries are being published on PyPI now….
jwhite242 commented on issue LLNL/maestrowf#443.
Oh, and one more comment. Having the full string in the match means we shouldn’t have to assume it’s the last line either, so just using the regex.search iterator should find a match on any line; should be safer in case those plugins also allow output after the jobid (would hope not, but easy enough to guard against that)….
grondo commented on issue hpc/Spindle#53.
Eh, like I said the naming isn’t critical, by default the Flux job shell will load *.so from the plugin search path, so either fluxspindle.so or libfluxspindle.so would work….
mplegendre commented on issue hpc/Spindle#53.
I’m cautious about going to spindle.so for the flux plugin. Spindle already has a libspindle.so for its user interface library, and mixing those names could be confusing. Could we symlink a spindle.so in the flux plugin space to a libspindleflux.so in the spindle space? …
BenWibking commented on issue LLNL/maestrowf#441.
> Think this might be what’s adding all that extra output on your cluster: https://slurm.schedmd.com/job_submit_plugins.html with some custom validation/logging messages always spit out (I’ll wager srun and salloc do the same?). Haven’t found anything yet about whether the order is always to dump out all these log messages prior to the job id line, but seems likely given most of this happens before the actual submission. Almost think it might be safer to leave the –parseable option off and have that regex account for ‘Submitted batch job’ prefix on the line so we can be sure the number we detect is actually the one we want? …
FrankD412 commented on issue LLNL/maestrowf#441.
I think the Submitted batch job <ID> format was standard if I’m not mistaken. It could be a simple regex for the initial submitted message and then parsing that line. That seems like the easiest fix.
…
