Issue Comment Events

Projects RADIUSS Home

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

View Comment

PhilipFackler commented on issue spack/spack#48875.

@spackbot fix style…

View Comment

adrienbernede commented on issue mfem/mfem#4684.

@v-dobrev as I said before, I think the handling of the --spec option in the tests/gitlab/build_and_test script was lacking robustness: It not trivial in bash to ensure that a “quoted string with white-spaces” is treated in a consistent way through several layer of scripts and/or variable resolutions. …

View Comment

tupek2 commented on issue mfem/mfem#4706.

Yes, I’m pretty confident the old version had an issue, but I’m not sure on the correct fix, or, for that matter, how to create a small reproducer….

View Comment

victorapm commented on issue hypre-space/hypre#1227.

Hi @RickGY,…

View Comment

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

## Codecov Report…

View Comment

grondo commented on issue flux-framework/flux-core#6649.

Thanks! I’ve set MWP….

View Comment

rzhangbq commented on issue mfem/mfem#4708.

I found that in https://github.com/mfem/mfem/issues/3826 that the vdim of FiniteElementSpace is not the dimension of the vector. So, can I ask,…

View Comment

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

The more I think about it…isn’t a Query most of the time just an Expression + Parallel Reduction?…

View Comment

JustinPrivitera commented on issue visit-dav/visit#20176.

The global mesh expressions are incorrectly calculated on a per-domain basis. Fixing this will require some retooling of the expression infrastructure….

View Comment

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

> The RV1 test that’s blowing up is t3027-resource-RV.t, but it looks like it might be an out of range error …

View Comment

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

I can’t help but think something like https://github.com/flux-framework/flux-core/issues/2547 or https://github.com/flux-framework/flux-core/pull/6210 is in play here. But that should all be shored up….

View Comment

cyrush commented on issue visit-dav/visit#20238.

One idea: …

View Comment

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

## Codecov Report…

View Comment

biagas commented on issue visit-dav/visit#20237.

Does disabling the popup messages not suffice? Options->Preferences->Enable warning message popups….

View Comment

mlohry commented on issue Alpine-DAV/ascent#478.

I’m not sure if it’s related to this enhancement, but is there a way to programmatically determine what, if any, files have been written after an Ascent::execute call, without resorting to checking the filesystem directly?…

View Comment

rfalgout commented on issue hypre-space/hypre#1195.

Hi @waynemitchell and @victorapm . This is ready for you to start reviewing. Thanks! …

View Comment

gberg617 commented on issue LLNL/axom#1478.

Update on the failing tests: The multiple_communicators test I added sporadically fails on Azure. This test is important to capture certain behavior when multiple communicators are sending/receiving messages. Looking into this, it sometimes fails when run with other unit tests (and only on Azure), but consistently passes when it is run by itself. I have heard that gtest+MPI is somewhat fragile in some cases, so I attempted to remove gtest from the tests I added by converting the ASSERT macros to my own version, and having each test become a function that is called within main() inside of lumberjack_NonCollectiveRootCommunicator.cpp. This fixes the issue, and both tests in this file always pass. Does the Axom team have any thoughts about potentially adding unit tests that do not use gtest? If there is a strong preference for requiring gtest, does anyone have thoughts on other solutions that can prevent these sporadic failures?…

View Comment

adrienbernede commented on issue LLNL/Umpire#924.

@davidbeckingsale ready to ship…

View Comment

adrienbernede commented on issue LLNL/RAJA#1774.

@rhornung67 Ready to ship….

View Comment

adrienbernede commented on issue LLNL/Caliper#627.

@daboehme ready to ship….

View Comment

adrienbernede commented on issue LLNL/CHAI#290.

@adayton1 ready to ship….

View Comment

adrienbernede commented on issue LLNL/CARE#307.

@adayton1 ready to ship. …

View Comment

oseikuffuor1 commented on issue hypre-space/hypre#1234.

Thanks Rob! …

View Comment

jesusbonilla commented on issue hypre-space/hypre#1230.

OK, thanks for you quick response!…

View Comment

yurivict commented on issue LLNL/zfp#250.

zfp is listed with the same maintainers that zfpy has….

View Comment

pelesh commented on issue LLNL/hiop#708.

While you are at it, you may want to remove stanza on custom CUDA installation from the README file. The workaround described there pertains to older versions of CMake and it is probably misleading for anyone with a reasonably recent CMake. See here for more recent CMake target names for CUDA libraries….

View Comment

najlkin commented on issue GLVis/glvis#325.

MFEM supports ParaView, VisIt and other (including Sidre) through DataCollection, where you enter the time level and time for every snapshot. I think it is a good idea to support those in general 👍 . In addition, we may then add some control to move between the levels….

View Comment

justinlaughlin commented on issue GLVis/glvis#325.

I agree that I don’t think we’d want to support this by socket, but it would be a very sensible feature for saved data. I believe the *.sol file type does not have the option to store time-dependent fields (please correct me if I’m wrong). We could use a filename convention (eg velocity_1.sol, velocity_2.sol, etc) but that convention is already used for parallel output….

View Comment

tzanio commented on issue GLVis/glvis#325.

Time navigation will be a useful extension, but it will require new infrastructure and significantly more memory than the current approach (which essentially holds a single instance at a time). …

View Comment

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

The data from previous times steps is discarded when a new time step is received, so going back is not supported at this point….

View Comment

Arpan3323 commented on issue LLNL/Umpire#932.

After building the project as a debug build and running my fuzz test in GDB, I have found the exact arguments for FixedMallocPool::FixedMallocPool(const std::size_t object_bytes, const std::size_t objects_per_pool) on which the error occurs. This should allow us to reproduce the error deterministically. Moreover, updating the fuzz test source to only supply these values to FixedMallocPool constructor results in a clear signal from AddressSanitizer as opposed to AddressSanitizer failing internal checks, which was the case earlier. …

View Comment

davidbeckingsale commented on issue LLNL/Umpire#932.

I think that’s a reasonable hypothesis. Are you able to reproduce this deterministically?…

View Comment

cyrush commented on issue LLNL/conduit#1361.

the reason:…

View Comment

chapman39 commented on issue LLNL/hatchet#155.

Closing, having been told from the Thicket team that Hatchet should not be used on lassen….

View Comment

Staudey commented on issue LLNL/zfp#227.

I see, that all makes sense. I’m going to take another stab at this tomorrow (or the day after tomorrow, depending on how much time I can find)…

View Comment

liyangrock commented on issue GEOS-DEV/LvArray#342.

> I’m not familiar with Kokkos. but no there really isn’t any unordered map or set in LvArray. If this data doesn’t need to go on the GPU then just use the standard libraries implementation….

View Comment