Issue Comment Events

Projects RADIUSS Home

jokervTv commented on issue spack/spack#42975.

Thanks @alalazo , it helps a lot….

View Comment

giordano commented on issue spack/spack#42879.

Nevermind, I managed to resolve my installation issues and could run the command requested: …

View Comment

teaguesterling commented on issue spack/spack#38922.

> I’m probably not the best person to review the Spack-specific build configuration. I will say this PR combines a lot of unrelated things, it might have been better to keep them separate. But that’s not too important I don’t think. I’m trying the latest commit and the build is failing for me (only default variants). …

View Comment

johnwparent commented on issue spack/spack#39739.

@scheibelp I believe I have addressed all outstanding comments. Ready for another round. …

View Comment

denislachapelle commented on issue mfem/mfem#4166.

@najlkin …

View Comment

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

## Codecov Report…

View Comment

v-dobrev commented on issue spack/spack#42839.

> Should we add depends_on('glu') to glew package.py? Should this be conditional on certain glew variants? …

View Comment

sebastiangrimberg commented on issue mfem/mfem#4065.

Updating here after debugging this odd misaligned address error. Walking through with cuda-gdb, the error is actually being encountered inside of cuSPARSE’s spMV, and in particular here is the true error message thrown by cuSPARSE: …

View Comment

v-dobrev commented on issue mfem/mfem#4173.

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch….

View Comment

najlkin commented on issue mfem/mfem#4151.

Ok, to add some concurrency here 😁 , I added this check (removed pfes->GetLocalTDofNumber(i) == -1) to #1951 ….

View Comment

codecov[bot] commented on issue flux-framework/flux-sched#1148.

## Codecov Report…

View Comment

jvwilliams23 commented on issue LLNL/lbann#2429.

> Hi @tbennun thanks for implementing this. I am wondering, is it possible for me to install this branch on your fork via spack? Or do I need to wait until the PR is merged? …

View Comment

adrienbernede commented on issue LLNL/RAJA#1609.

Marked the PR as [draft]. I’d like to run some more tests….

View Comment

ollielo commented on issue LLNL/Caliper#535.

I tried what you suggested. Here is the relevant part of the log …

View Comment

adayton1 commented on issue LLNL/CHAI#251.

> You should also update the version in the ‘make_release_tarball’ script …

View Comment

adrienbernede commented on issue LLNL/CHAI#245.

@adayton1 I got the CI green, however Umpire does build with libcpp: https://lc.llnl.gov/gitlab/radiuss/Umpire/-/jobs/1720331 …

View Comment

cnpetra commented on issue LLNL/hiop#678.

closing this since a partial fix has been done in PR #676. We will remove RAJA as a dependency in the not-so-far future….

View Comment

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

Thanks for consolidating the information @grondo!…

View Comment

s-u commented on issue LLNL/sundials#409.

Thanks, much appreciated!…

View Comment

ibaned commented on issue LLNL/blt#611.

I would also like to have a resolution to this, it seems like an inappropriate code smell for the central CMake toolbox at Livermore to be emitting these warnings in all downstream projects, especially given the “will be removed from a future version” part of the warning….

View Comment

iljah commented on issue visit-dav/visit#19346.

> What is the purpose of using the symlink? …

View Comment

markcmiller86 commented on issue visit-dav/visit#19346.

> What is the purpose of using the symlink? …

View Comment

iulian787 commented on issue visit-dav/visit#19348.

I am building from current develop branch …

View Comment

pratikvn commented on issue LLNL/sundials#400.

Thanks! That seems to work. Feel free to try this out with the latest Ginkgo develop and let me know if you face any issues. …

View Comment

pramodk commented on issue LLNL/Caliper#529.

Sorry for delay. We will try to create one and share with you….

View Comment

Wayne901 commented on issue GLVis/glvis#276.

Thank you. Installing libXi-devel solved the problem….

View Comment

v-dobrev commented on issue GLVis/glvis#274.

> Like many visualization applications GLVis consists of multiple threads / workers that does different things, is that correct? …

View Comment

Staudey commented on issue LLNL/zfp#227.

Thanks for the heads-up! I’ll have to take another look at this because what I first thought the appveyor issue was turned out to be a red herring….

View Comment

systemed commented on issue LLNL/zfp#228.

That’s great to know - thank you. I’ll go with compressing at application startup for now, but move to deserialization when that’s available….

View Comment

lindstro commented on issue LLNL/zfp#228.

I’m afraid we didn’t have time to work out (de)serialization with the const_array classes for the 1.0.x releases, but it is likely that this will be supported in the next release. We have to deal with the same issue to support parallel variable-rate decompression, where we need to quickly locate any given block in the compressed stream. We’re essentially using the same block offset coding strategy for that. Because we cannot embed these block offsets in the compressed stream while retaining backwards compatibility, we need for the block index to be stored separately, and we’re currently working on support for (de)serializing this auxiliary data….

View Comment

altineller commented on issue GLVis/glvis#274.

> I’m not really sure if it is possible to use an SDL2 application (GLVis) inside a Qt application (your application). Maybe you can check the SDL2 forums and issues, see https://www.libsdl.org. …

View Comment

yslan commented on issue Alpine-DAV/ascent#1252.

False alert… …

View Comment

ltaylor16 commented on issue LLNL/shroud#343.

Thanks for the report. I was able to reproduce the problem with your example. It’ll be next week before I can start on a fix. …

View Comment

cyrush commented on issue LLNL/blt#676.

resolved in #679 …

View Comment

cielling commented on issue LLNL/Caliper#536.

@daboehme Having an append option would be great. Thanks for looking into this!…

View Comment

b100dian commented on issue LLNL/zfp#225.

Yes, in this particular example the control points are like non-existent, meaning there are no curves. …

View Comment

jwhite242 commented on issue LLNL/maestrowf#424.

> @jwhite242 – Is this a dead end at this point? We’re assessing Maestro and it’s looking like DFS would be good on our end too. Wondering just in case we need to revisit. …

View Comment

joetristano commented on issue GLVis/glvis#272.

Would love to have this feature!!!! Was just wondering about the same thing. Redundant data tranfer can be easily eliminated……

View Comment

S-o-T commented on issue LLNL/zfp#133.

Thanks! Can you share an ETA for next release?…

View Comment

jwhite242 commented on issue LLNL/merlin#467.

Yeah, for those monolithic environments, frozen dependencies would definitely cause problems, as Lina noted. They are great for reproducible dev work, and with the github ci though where you’re only exercising merlin. Maybe worth retaining non-frozen requirements with softer and more flexible bounds for the main build system and keep the second lock file for building environments with for the devs? Maestro does this with poetry where the lock file is separate, and only really gets activated if installing with poetry, but the pip installs get the more relaxed version.

View Comment

LinaMuryanto commented on issue LLNL/merlin#467.

> Per @doutriaux1’s request: @jwhite242 @LinaMuryanto do either of you have any thoughts regarding freezing requirements for a release? Could this potentially break the WEAVE venv? …

View Comment

corbett5 commented on issue GEOS-DEV/LvArray#316.

Both have been merged, but might as well link the two comments. …

View Comment

vsoch commented on issue LLNL/maestrowf#434.

> So, bundling these two as they’re closely related. First, just to clarify and make sure we’re talking about the same thing, I was really asking about what the ‘cmd’ block in the maestro spec looks like in this mode. Currently they’re all bash, so question was aimed really at does the step definition in the maestro spec change appreciably for this mode, or is the only real difference being that the step’s cmd/script is just executing in a container vs by an hpc scheduler? …

View Comment

kswartz92 commented on issue LLNL/hiop#681.

At first glance this look like exactly what we need, thanks @cnpetra!…

View Comment

cameronrutherford commented on issue LLNL/hiop#676.

I made #680 to track Incline CI fixing and other associated issues that could be fixed by a CI re-vamp. This can be merged from my perspective, and Spack PR was merged this morning….

View Comment

BenWibking commented on issue LLNL/maestrowf#436.

> No, it doesn’t look like there’s a better way built in to set any extra/un-known sbatch options than what you’re currently doing by putting them at the top of your step cmd. …

View Comment

CamStan commented on issue LLNL/scr#587.

There is a way to tell ReadTheDocs to build doc changes from pull requests and have it as a required check before merging. I played with this a couple months ago with UnifyFS, but have yet to get it to work properly. It’s a new feature, so might be getting things ironed out still….

View Comment

dependabot[bot] commented on issue LLNL/scr#584.

OK, I won’t notify you again about this release, but will get in touch when a new version is available. If you’d rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version….

View Comment

wsheat commented on issue XBraid/xbraid#95.

Thank you for your reply. It works!…

View Comment

jbschroder commented on issue XBraid/xbraid#95.

Hi, …

View Comment