Re: [Rd] using Paraview "in-situ" with R?
Thanks. I take it though you see "R" in this role as adding to the capabilities of the viewers, maybe adding some quick model fits over FEM results or something? Right now I was imagining working with freefem and rolling my own c++ code with supporting use of R code. Ideally I could easily overlay stuff without messing around with temp files. There are a lot of R things, probably optimizations etc, that may be nice to view as they progress with more than just a figure of merit. Right now I'm just trying to use Runge-Kutta on a simple orbit and the mjmdatascope output is much more useful on-the-fly than text or after the fact. Mike Marchywka 44 Crosscreek Trail Jasper GA 30143 was 306 Charles Cox Drive Canton, GA 30115 470-758-0799 404-788-1216 From: George Ostrouchov Sent: Wednesday, January 10, 2024 3:06 PM To: r-devel@r-project.org Cc: Mike Marchywka Subject: Re: [Rd] using Paraview "in-situ" with R? At ORNL, we worked with VisIt (a sibling of Paraview, both funded largely by DOE) around 2016 and made an in situ demo with R. We used packages pbdMPI (on CRAN) and pbdDMAT (on GitHub/RbigData), which were in part built for this purpose. Later also the package hola (on GitHub/RbigData) was built to connect with adios2, which can do buffered in situ connections with various codes. But the VisIt developers were not interested in R (preferring to roll their own), so that direction fizzled. Paraview is a competetive sibling of VisIt, so I don’t know if they would be interested. The packages we developed are viable for that purpose. There is a lot in R that could benefit Paraview (or VisIt). George > > Message: 1 > Date: Tue, 9 Jan 2024 14:20:17 + > From: Mike Marchywka > To: R-devel > Subject: [Rd] using Paraview "in-situ" with R? > Message-ID: > > > > Content-Type: text/plain; charset="iso-8859-1" > > I had previously asked about R interfaces to various "other" visualization > tools specifically lightweights for monitoring progress of > various codes. I was working on this, > > https://github.com/mmarchywka/mjmdatascope > > but in the meantime found out that Paraview has an "in-situ" > capability for similar objectives. > > https://discourse.paraview.org/t/does-or-can-paraview-support-streaming-input/13637/9 > > While R does have a lot of plotting features, > it seems like an excellent tool to interface to R allowing visualization > without > a bunch of temp files or > > Is anyone aware of anyone doing this interface or reasons its a boondoggle? > > Thanks. > > > > Mike Marchywka > 44 Crosscreek Trail > Jasper GA 30143 > was 306 Charles Cox Drive Canton, GA 30115 > 470-758-0799 > 404-788-1216 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using Paraview "in-situ" with R?
Thanks for adding more explanation. As Ivan Krylov mentioned earlier, this sounds like an idea for developing an R package. The viewers and R largely operate in communities that so far have little interaction and both can benefit from ideas in the other. George > On Jan 11, 2024, at 6:30 AM, Mike Marchywka wrote: > > Thanks. I take it though you see "R" in this role as adding to the > capabilities of > the viewers, maybe adding some quick model fits over FEM results or something? > Right now I was imagining working with freefem and rolling my own c++ code > with supporting use of R code. Ideally I could easily overlay stuff without > messing around with temp files. There are a lot of R things, probably > optimizations etc, that may be nice to view as they progress > with more than just a figure of merit. > Right now I'm just trying to use Runge-Kutta on a simple orbit > and the mjmdatascope output is much more useful on-the-fly > than text or after the fact. > > > Mike Marchywka > 44 Crosscreek Trail > Jasper GA 30143 > was 306 Charles Cox Drive Canton, GA 30115 > 470-758-0799 > 404-788-1216 > > > > > > From: George Ostrouchov > Sent: Wednesday, January 10, 2024 3:06 PM > To: r-devel@r-project.org > Cc: Mike Marchywka > Subject: Re: [Rd] using Paraview "in-situ" with R? > > At ORNL, we worked with VisIt (a sibling of Paraview, both funded largely by > DOE) around 2016 and made an in situ demo with R. We used packages pbdMPI (on > CRAN) and pbdDMAT (on GitHub/RbigData), which were in part built for this > purpose. Later also the package hola (on GitHub/RbigData) was built to > connect with adios2, which can do buffered in situ connections with various > codes. > > But the VisIt developers were not interested in R (preferring to roll their > own), so that direction fizzled. Paraview is a competetive sibling of VisIt, > so I don’t know if they would be interested. The packages we developed are > viable for that purpose. There is a lot in R that could benefit Paraview (or > VisIt). > > George > >> >> Message: 1 >> Date: Tue, 9 Jan 2024 14:20:17 + >> From: Mike Marchywka >> To: R-devel >> Subject: [Rd] using Paraview "in-situ" with R? >> Message-ID: >> >> >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> I had previously asked about R interfaces to various "other" visualization >> tools specifically lightweights for monitoring progress of >> various codes. I was working on this, >> >> https://github.com/mmarchywka/mjmdatascope >> >> but in the meantime found out that Paraview has an "in-situ" >> capability for similar objectives. >> >> https://discourse.paraview.org/t/does-or-can-paraview-support-streaming-input/13637/9 >> >> While R does have a lot of plotting features, >> it seems like an excellent tool to interface to R allowing visualization >> without >> a bunch of temp files or >> >> Is anyone aware of anyone doing this interface or reasons its a boondoggle? >> >> Thanks. >> >> >> >> Mike Marchywka >> 44 Crosscreek Trail >> Jasper GA 30143 >> was 306 Charles Cox Drive Canton, GA 30115 >> 470-758-0799 >> 404-788-1216 >> > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Choices to remove `srcref` (and its buddies) when serializing objects
Dear R devs,
I was digging into a package issue today when I realized R serialize function
not always generate the same results on equivalent objects when users choose to
run differently. For example, the following code
serialize(with(new.env(), { function(){} }), NULL, TRUE)
generates different results when I copy-paste into console vs when I use
ctrl+shift+enter to source the file in RStudio.
With a deeper inspect into the cause, I found that function and language get
source reference when getOption("keep.source") is TRUE. This means the source
reference will make the functions different while in most cases, whether
keeping function source might not impact how a function behaves.
While it's OK that function serialize generates different results, functions
such as `rlang::hash` and `digest::digest`, which depend on `serialize` might
eventually deliver false positives on same inputs. I've checked source code in
digest package hoping to get around this issue (for example serialize(...,
refhook = ...)). However, my workaround did not work. It seems that the markers
to the objects are different even if I used `refhook` to force srcref to be the
same. I also tried `removeSource` and `rlang::zap_srcref`. None of them works
directly on nested environments with multiple functions.
I wonder how hard it would be to have options to discard source when
serializing R objects?
Currently my analyses heavily depend on digest function to generate file caches
and automatically schedule pipelines (to update cache) when changes are
detected. The pipelines save the hashes of source code, inputs, and outputs
together so other people can easily verify the calculation without accessing
the original data (which could be sensitive), or running hour-long analyses, or
having to buy servers. All of these require `serialize` to produce the same
results regardless of how users choose to run the code.
It would be great if this feature could be in the future R. Other pipeline
packages such as `targets` and `drake` can also benefit from it.
Thanks,
- Dipterix
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
