search

GollyGang / ready

A cross-platform implementation of various reaction-diffusion systems and PDEs.
GNU General Public License v3.0
761 stars 60 forks source link

Better parameter maps #80

Open timhutton opened 4 years ago

timhutton commented 4 years ago

One user wrote:

Better interaction with Parameters. ie. "The parameters k1, k2, F1 and F2 define the current range of the map. Change them to explore." (parameter-map.vti (Gray-Scott/U-Skate) That sentence alone didn't do much for me. I literally had to try one by one to see what was really changing. It would be also nice to know the limits, ie. k1 starts with 0.03 value and "explodes" with 0.07, I didn't know the values were so small (my first try for k1 was 10.00 lol)

It is kind of neat that we are able to support parameter maps without any UI coding, just by using the coordinates in the formula/kernel. But the downside is that the user is left somewhat baffled by the complexity presented to them - no labelled axes, no zoom in/out function, etc.

danwills commented 4 years ago

I see the problem here, and it seems like you could go a few ways to try to address it in Ready:

One way might be via specially treated parameters (that link up to some extra ui bits)?

And perhaps another option could be to introduce a framework to be able to easily swap in an additional reagent as a parameter value.

The second option could give more opportunities for being able to paint or regenerate the map on-the-fly for example. Could be less good for the drawing-an-axis aspect of the idea however!

Would love to help with this if I can! Dan

On Wed, 22 Jul 2020, 7:29 pm Tim Hutton, notifications@github.com wrote:

One user wrote:

Better interaction with Parameters. ie. "The parameters k1, k2, F1 and F2 define the current range of the map. Change them to explore." (parameter-map.vti (Gray-Scott/U-Skate) That sentence alone didn't do much for me. I literally had to try one by one to see what was really changing. It would be also nice to know the limits, ie. k1 starts with 0.03 value and "explodes" with 0.07, I didn't know the values were so small (my first try for k1 was 10.00 lol)

It is kind of neat that we are able to support parameter maps without any UI coding, just by using the coordinates in the formula/kernel. But the downside is that the user is left somewhat baffled by the complexity presented to them - no labelled axes, no zoom in/out function, etc.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GollyGang/ready/issues/80, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEDSJXEVSEFQUYSXLHPKB3R422AJANCNFSM4PEREHLA .

timhutton commented 4 years ago

Hi Dan,

I can see option 1 working and I think we should do something like this. Formula rules could keep their usual formula which is nice. Kernel rules (e.g. smoothLifeL_parameter_map.vti) would need to handle the pixel coordinates inside their code but the UI could set the map limits (b1a, b1b, etc. in that example) so it would still work.

The second option can already be partly achieved by having two extra chemicals and a horizontal/vertical linear gradient in their initial pattern generators. The parameter_modulation_demo*.vti patterns work using extra chemicals like this, and allow you to paint in the map parameters. If we had UI for controlling the IPG (which is already on our TODO list) then this would be a workable solution for parameter maps. This option allows fancy things like radial gradients, as parameter_modulation_demo2.vti shows. But I'm less keen on wasting memory like this - it slows down the runtime since it has to be transferred between GPU and CPU frequently.

timhutton commented 4 years ago

As a first step, and something that should be done anyway, now I think about it: we should pull the global fixed parameters out of kernel rules into named parameters in the UI. At runtime Ready would prepend the kernel code with global float variables containing the current values.

danwills commented 4 years ago

Option 1 for sure! definitely the easier place to start (and both options could still play-in eventually)

And what do you think about how this extra UI behaviour should be triggered? Should it be by the formula? Wouldn't it be cool if this could apply to any pair of parameters (in 2d) without editing the formula source? (I guess that's steadily edging towards option 2) Maybe we could think about some extra tags in the formula xml (or in the formula source like a pragma or decorator) that tell Ready which parameters are meant to be mappable?

I think it would be really cool to be able to kinda switch any formula into 'map mode' and choose whichever parms you want as the map-axes. But maybe that would be a bit complicated to do.

Scrolling down in thought-space to option-2 (which seems more of a pie in a longer term sky), I think it would be good just to keep the possibilities open for multi-dimensional maps (not only 2d), despite the difficulties that might imply in fitting them nicely into 2d viewing space, I still think it would be worth making something general enough that it could cope with mapping more than two parameters at once.

On a similar kind of thread, but one step less meta I guess (reagents vs parameters), I've been thinking for a long time about the possibility to be able to paint values into all reagents (or a subset of them) at once, instead of only one at a time. I think that could be very helpful in some cases (especially in the getting-things-started aspect of sensitive-startup formulas). We might also want to look into speeding up the painting implementation somehow for this to be more nice to use.

Is one possibility for paint to become much faster for there to be some openCL kernel running in the same pipeline as (or even part of the source of) the main one, that we can pass locations/radiuses to and it would modify the sim opencl-vram buffers for us? I think I can imagine how that might work, if I get inspired I'll make a branch and see if I can work anything out.

And now I know this is a bit tangential (and maybe not in a way!) but wouldn't it be lovely if the kernel parameters were not baked into the source of the kernel but instead were all arguments to the kernel, so that they could be changed at any time without recompiling the kernel? This would allow us to have like a real-time (no slowdown for recompiling) adjuster for parameter values. There's still my old prototype branch in the repo where I got something working for that.

I think it's easy to see how parms-as-kernel-arguments might also make some idea of a 'local-parameter-map-explorer' more practical too: Here I'm more imagining a grid of individual simulations, each with its own position in 'parameter map space'. If the map-coordinates could be arguments there could be way less recompiling the kernel! I really think something like this could help greatly in exploring and ultimately navigating parameter spaces of RDs in Ready.

Many foods for many thoughts, and if I can help prototype any of it, I certainly shall.

On Fri, Jul 24, 2020 at 10:45 PM Tim Hutton notifications@github.com wrote:

As a first step, and something that should be done anyway, now I think about it: we should pull the global fixed parameters out of kernel rules into named parameters in the UI. At runtime Ready would prepend the kernel code with global float variables containing the current values.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GollyGang/ready/issues/80#issuecomment-663532625, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEDSJWU2R5FATNFFN6COFDR5GCORANCNFSM4PEREHLA .

danwills commented 4 years ago

Seems a bit like (at least for formula-mode kernels) it might be possible to have a switchable system where any particular parameter may either: Go in the body of the kernel (like they currently do), or go in as a kernel argument, or go in (as like a super-mappable option, also likely requiring recompile), as a reagent-value.

I think that some abstraction like that could potentially enable a lot of the options discussed above all at once.

On Fri, Jul 24, 2020 at 11:51 PM Dan Wills gdanzo@gmail.com wrote:

Option 1 for sure! definitely the easier place to start (and both options could still play-in eventually)

And what do you think about how this extra UI behaviour should be triggered? Should it be by the formula? Wouldn't it be cool if this could apply to any pair of parameters (in 2d) without editing the formula source? (I guess that's steadily edging towards option 2) Maybe we could think about some extra tags in the formula xml (or in the formula source like a pragma or decorator) that tell Ready which parameters are meant to be mappable?

I think it would be really cool to be able to kinda switch any formula into 'map mode' and choose whichever parms you want as the map-axes. But maybe that would be a bit complicated to do.

Scrolling down in thought-space to option-2 (which seems more of a pie in a longer term sky), I think it would be good just to keep the possibilities open for multi-dimensional maps (not only 2d), despite the difficulties that might imply in fitting them nicely into 2d viewing space, I still think it would be worth making something general enough that it could cope with mapping more than two parameters at once.

On a similar kind of thread, but one step less meta I guess (reagents vs parameters), I've been thinking for a long time about the possibility to be able to paint values into all reagents (or a subset of them) at once, instead of only one at a time. I think that could be very helpful in some cases (especially in the getting-things-started aspect of sensitive-startup formulas). We might also want to look into speeding up the painting implementation somehow for this to be more nice to use.

Is one possibility for paint to become much faster for there to be some openCL kernel running in the same pipeline as (or even part of the source of) the main one, that we can pass locations/radiuses to and it would modify the sim opencl-vram buffers for us? I think I can imagine how that might work, if I get inspired I'll make a branch and see if I can work anything out.

And now I know this is a bit tangential (and maybe not in a way!) but wouldn't it be lovely if the kernel parameters were not baked into the source of the kernel but instead were all arguments to the kernel, so that they could be changed at any time without recompiling the kernel? This would allow us to have like a real-time (no slowdown for recompiling) adjuster for parameter values. There's still my old prototype branch in the repo where I got something working for that.

I think it's easy to see how parms-as-kernel-arguments might also make some idea of a 'local-parameter-map-explorer' more practical too: Here I'm more imagining a grid of individual simulations, each with its own position in 'parameter map space'. If the map-coordinates could be arguments there could be way less recompiling the kernel! I really think something like this could help greatly in exploring and ultimately navigating parameter spaces of RDs in Ready.

Many foods for many thoughts, and if I can help prototype any of it, I certainly shall.

On Fri, Jul 24, 2020 at 10:45 PM Tim Hutton notifications@github.com wrote:

As a first step, and something that should be done anyway, now I think about it: we should pull the global fixed parameters out of kernel rules into named parameters in the UI. At runtime Ready would prepend the kernel code with global float variables containing the current values.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GollyGang/ready/issues/80#issuecomment-663532625, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEDSJWU2R5FATNFFN6COFDR5GCORANCNFSM4PEREHLA .