Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
Activity
• 13:55

kanav99 on gh-pages

build based on 1428da8 (compare)

• 13:39

KirillZubov on master

replace gpu tests update fix some thing and 3 more (compare)

• 13:39
KirillZubov closed #240
• 10:31
TorkelE commented #290
• 07:09
yewalenikhil65 commented #292
• 05:58
yewalenikhil65 commented #292
• 04:22
ChrisRackauckas closed #368
• 04:22
ChrisRackauckas commented #368
• 04:21
ChrisRackauckas opened #385
• 04:19
ChrisRackauckas opened #384
• 04:17
ChrisRackauckas commented #368
• 03:26
ChrisRackauckas commented #719
• 01:19
isaacsas commented #290
• 01:18
isaacsas commented #290
• 01:01

christopher-dG on 173ec862-done

• 01:01

christopher-dG on 173ec862-done

https://gitlab.com/JuliaGPU/Dif… (compare)

• 01:01

christopher-dG on 33306ba4-done

• 01:01

christopher-dG on 33306ba4-done

https://gitlab.com/JuliaGPU/Dif… (compare)

• 00:43
• Jan 22 22:27
anandijain opened #719
BridgingBot
@GitterIRCbot
[slack] <dalarev> https://discourse.julialang.org/t/efficient-way-of-doing-linear-regression/31232/33 post tells me it's probably the most accurate, but my A matrix comprises derivative operators, so I'm also looking at DiffEqOperators.
BridgingBot
@GitterIRCbot
[slack] <mschauer> Solve the normal equations:
gmres(A'*A, A'*y)
[slack] <mschauer> and then perhaps with a solver which uses the Hermitian structure… ah, you just said so much
BridgingBot
@GitterIRCbot
[slack] <mschauer> use conjugate gradient descent on the normal equations, tells me a helpful voice
BridgingBot
@GitterIRCbot
[slack] <Jose Daniel Lara> @chrisrackauckas is there a more updated version of Benchmarks vs Matlab solvers from DiffEq?
BridgingBot
@GitterIRCbot
BridgingBot
@GitterIRCbot
[slack] <dalarev> From the discourse post I linked to, it sounds like doing A'A could square my errors, and I think for my application accuracy is most important.
[slack] <mschauer> Well, can you do QR? Then do it. I assumed that you use an iterative solver because you must
BridgingBot
@GitterIRCbot

[slack] <yingbo_ma> Seems like we are also getting

Builds have been temporarily disabled for public repositories due to a negative credit balance. Please go to the Plan page to replenish your credit balance or alter your Consume paid credits for OSS setting.

BridgingBot
@GitterIRCbot
[slack] <David Millard> Hi, I have a second order ODE in a classical mechanics context. Is SecondOrderODEProblem still supported? I had a hard time understand what inputs the dynamics function should take. Unfortunately reading https://github.com/SciML/DiffEqBase.jl/blob/864c379ead274243acdd965bd8942d1da1deb3bb/test/problem_creation_tests.jl#L51 didn't shed a lot of light for me. I'm not sure what the relationship between u and v are, and the docstring args from the SecondOrderODEProblem constructor seems flipped compared to its implementation. Thanks for any information!
[slack] <chrisrackauckas> @David Millard https://tutorials.sciml.ai/html/models/01-classical_physics.html should help
BridgingBot
@GitterIRCbot
[slack] <David Millard> That's exactly what I was missing. Thank you!
BridgingBot
@GitterIRCbot
[slack] <jonas.isensee> Hi,
what's the best way to implement a system where I have states of the form u0 = (rand(3), rand(3,3))
I know that I can just work with u0 = rand(3,4) but that makes the eoms rather ugly. The above doesn't work though
[slack] <chrisrackauckas> RecursiveArrayTools.ArrayPartition
BridgingBot
@GitterIRCbot

[slack] <jonas.isensee> Thanks you, that seems to work.
Not sure that is much better for my particular usecase though.
I want to work with the matrix directly and
u.x[2] is probably not much better than@view u[:,2:4]
at the cost of introducing another abstraction layer.

(relevant since this is for teaching...)

BridgingBot
@GitterIRCbot
[slack] <chrisrackauckas> views are probably a nice canonical way to do it if it's simple enough
[slack] <chrisrackauckas> LabelledArrays.jl is another.
BridgingBot
@GitterIRCbot

[slack] <jonas.isensee> Ha, I didn't know that package! This looks really cool.

For the sake of the students I will probably still stick to regular views
but I'll see if I can incorporate that into my normal work 🙂

[slack] <jonas.isensee> Thanks for your help
[slack] <chrisrackauckas> no problem
[slack] <chrisrackauckas> ComponentArrays.jl is another cool package along those lines.
BridgingBot
@GitterIRCbot
[slack] <jonas.isensee> Incredible. I'm having a "Why did I not know this" moment
BridgingBot
@GitterIRCbot

[slack] <David Millard> Hi, I'm sure I'm misusing VectorContinuousCallback, but I can't seem to figure out why. I effectively have a slightly fancier version of the bouncing ball example, where the bottom points of a mesh make inelastic contact with a floor plane at z = 0.

The multi-wall bouncing ball works fine for me. However, I can't seem to convince the affect! function to trigger in my program. Relevant bits:
z(u) = view(u, 3, :, 1)
dz(u) = view(u, 3, :, 2)
floor_cond(out, u, t, int) = out .= ifelse.(z(u) .> 0, z(u), 0)

function floor_affect!(int, idx)
z(int.u)[idx] = 0
dz(int.u)[idx] = 0
end

floor_cb = VectorContinuousCallback(floor_cond, floor_affect!, nothing, size(state, 2); rootfind=false)

prob = ODEProblem{true}(elastic_dynamics!, state, (0, 1 / 60), params)
sol = solve(prob, callback=floor_cb; dt=1e-4) Settingzanddzto 0 yields the behavior I want in my own dinky homemade Euler solver, where I just check the z-coord and apply the affect with anif block.

Secondary meta question: is this the right venue for questions like this?

Marc Berliner
@MarcBerliner
In ModelingToolkit.jl, is there anything similar to the subs command from MATLAB's symbolic toolbox?
BridgingBot
@GitterIRCbot
[slack] <chrisrackauckas> what does that do?
Marc Berliner
@MarcBerliner
It replaces a symbolic variable with a number or array. E.g. subs(x+y, x, 1) = 1+y
BridgingBot
@GitterIRCbot
[slack] <chrisrackauckas> substitute?
Marc Berliner
@MarcBerliner
Thanks! I missed that in the doc
BridgingBot
@GitterIRCbot
[slack] <chrisrackauckas> no problem
dimitri-voytan
@dimitri-voytan

Hi, I'm new to Julia and the Neural PDE library, and I was wondering if there if is a way to implement the following idea in the Physics Informed Neural Network.

Take for example the 1D Poisson eq. $u_{xx} = f$ with $u(0) = u(1) = 0$. This could be solved by taking the neural network output (call it $ũ$) and multiplying it by $x(x-1)$. Since this polynomial is zero on the boundary, the boundary conditions are automatically enforced, and the PDE is enforced with $u = ũ*x*(x-1)$.

I tried doing something like this by

@variables u(..)
@parameters x
@derivatives Uxx''~x
eq = Uxx(u(x)*x*(x-1.0) )~ 1

and then following (and modifying dimensions where appropriate) the rest of the tutorial at https://github.com/SciML/NeuralPDE.jl

When I do this, I get UndefVarError: *_d not defined. Everything runs as expected when I use
eq = Uxx(u(x) )~ 1, so maybe multiplication between parameters and variables is undefined? Is there a way I can implement this?

Any help would be appreciated.

Christopher Rackauckas
@ChrisRackauckas
@dimitri-voytan yeah... that's not in the automated form. But it's in the very old 1992 paper on solving PDEs with NNs, and I've thought about it
4:00
it's hard to automate that because it can be specific to the equation
Mihaly Koltai
Hi, can I do matrix multiplication within the ODE in diffeqr (so using the solver from R)? If i try to do it, eg. for the Lorentz equation:
'f_ode_julia_vect <- function(u,x,t) {du=x %% u + c(0,-u[1]u[3],u[1]u[2]); return(du) }
prob<-de_jul\$ODEProblem(f_ode_julia_vect, u0,tspan,K_lor); fastprob=diffeqr::jitoptimize_ode(de_jul,prob)'
where K_lor is a 3x3 matrix I keep getting the error 'Error in x %
% u : requires numeric/complex matrix/vector arguments'
Christopher Rackauckas
@ChrisRackauckas
@mbkoltai_twitter you can do it, but I guess not with the JIT. Can you open an issue on JIT compilation of matmuls?
Mihaly Koltai
opened an issue at SciML/diffeqr#28
dimitri-voytan
@dimitri-voytan
@ChrisRackauckas Thanks for getting back to me and letting me know that it was done a while back. Yes, a generalized version would be more difficult, depending on the domain.
@spraharsh
I have a somewhat generic question about implicit ODE solvers, most implicit ODE solvers I know use newton-raphson with the jacobian to get roots, are there situations in which they don't capture the gradient flow if the jacobian has some 0 eigenvalues but not all (say I have a saddle in a subspace). I'm asking because inverting the jacobian for newton raphson would not be possible.
@spraharsh
nvm I figured it out. thanks
Arjun Narayanan
@ArjunNarayanan
Hi, I had a question about some of the GSoC projects described under Numerical Differential Equations Projects. I was wondering if this is the right place to talk about it? Thanks!
Christopher Rackauckas
@ChrisRackauckas
@ArjunNarayanan this is a great place to discuss them!
I'd recommend joining the Slack though: julialang.org/slack
sometimes the bridge to the Gitter breaks
Arjun Narayanan
@ArjunNarayanan
Okay, thank you!
BridgingBot
@GitterIRCbot
[slack] <Arjun Narayanan> Ah, I understand. Is the convention in DiffEqOperators to discretize at the center points?
[slack] <chrisrackauckas> Just periodic BCs have this issue, but periodic kind of needs to do it in order to be well-defined
BridgingBot
@GitterIRCbot
[slack] <Arjun Narayanan> Got it. It might be worth treating the case where we discretize at the grid points? Because that is quite conventional in finite difference methods and might get confusing for users...
BridgingBot
@GitterIRCbot
[slack] <chrisrackauckas> yes, I think there is an issue open about doing it
BridgingBot
@GitterIRCbot
[slack] <Arjun Narayanan> Okay, thank you!
BridgingBot
@GitterIRCbot
[slack] <Arjun Narayanan> I can't seem to find that issue. Should I work under the assumption that PeriodicBC is a special case that requires discretizations to be at cell centers? It seems quite awkward.
BridgingBot
@GitterIRCbot
[slack] <chrisrackauckas> let's open an issue to discuss it more
BridgingBot
@GitterIRCbot

[slack] <Arjun Narayanan> I am noticing some strange behavior with upwinding. Here is my simple example for the advection equation (taking into account the periodicity mistake I made earlier)

using OrdinaryDiffEq
using DiffEqOperators

derivative_order = 1
approximation_order = 1
speed = -1.
len = 20
dx = (1.0)/(len-1)
x = collect(range(dx/2,1.0-dx/2,length=len-1))
CFL = 0.5
dt = CFL*dx/abs(speed)
stoptime = 5dt

op = UpwindDifference(derivative_order,approximation_order,dx,len,speed)
bc = PeriodicBC(eltype(x))

exactsoln(x,a,t) = sin.(4pix .- at)
u0 = exactsoln(x,speed,0.0)
du0 = opbcu0

soln = solve(prob,Euler(),dt=dt)