Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
    Christoph Ortner
    Though I’d probably still need ApproxFun to evaluate the basis functions...
    In general, I wonder whether a “manual mode” of ApproxFun might be useful. I noticed e.g. that restricting the degree in \ rather than the tolerance throws warnings even if it is intended. By “manual mode” I mean non-adaptive.
    Sheehan Olver
    The long term plan is to do “Manual mode” via https://github.com/JuliaApproximation/ContinuumArrays.jl. This will also support FEM (in fact @jagot has a package for splines building on ContinuumArrays.jl) and make it possible to use distributed memory.
    Stefanos Carlström
    Actually, I don't, yet :)
    I have a FEDVR package
    But that is a bit limited at the moment, in that it only supports Dirichlet1 boundary conditions, since I've yet to fix the issue with restriction matrices (i.e. dropping the first and last basis functions)
    Sheehan Olver
    In any case, it’s kind of on the back burner as I have a backlog of about 10 papers to finish (and probably papers help more with promotion then making another package that does basically the same thing as ApproxFun 😅). But the basics are already implemented.
    Mitko Georgiev
    Thank you @dlfivefifty ,
    i think i will start with reading the Alex Townsend's paper behind FastAsyTransforms.mand may be in long turn
    i may figure out how to do HankelTransform(Fun)->Fun.
    Don MacMillen
    I guess I don't really understand the support for Complex numbers in ApproxFun. If I try to evaluate a complex argument to a Fun(cos) then it returns zero if the imaginary part is non zero. Curiously, it will return a complex number with a correct real part if the imaginary part of the input is zero. Also, I can easily create Fun's with complex coefficients that will return a complex number when evaluating a real number, but again will return zero if the imaginary part is non-zero. Here are a few examples. (I believe all of these work in Chebfun, btw.)
    julia (v1.2)> f = Fun(cos);
    julia (v1.2)> f(.1)
    julia (v1.2)> f(.1 + .1im)
    julia (v1.2)> f(.1 + .0im)
    0.9950041652780257 + 0.0im
    julia (v1.2)> g = Fun(Chebyshev(), randn(Complex{Float64}, 20));
    julia (v1.2)> g(.1)
    2.1013219596855888 - 0.11052912191219874im
    julia (v1.2)> g(.1 + .1im)
    0.0 + 0.0im
    julia (v1.2)> cos(.1 + .1im)
    0.9999833333373015 - 0.00999998888888977im
    Sheehan Olver
    evaluation is only well defined on the domain of the function, which is -1..1 by default. Otherwise it returns zero.
    If you want to evaluate on a domain in the complex plane you can use say a Circle or Segment
    I’d be shocked if those work in Chebfun unless it is doing extrapolation which is numerically dangerous. But you can use extrapolate(f,x) in ApproxFun if you wish
    Don MacMillen
    Thanks. I see your point. It does look, however, that Chebfun takes more of a "let the buyer beware" type of view. It looks like it will happily evaluate many complex args. As long as you are inside of the Bernstein ellipse, life is good. It will even plot the Bernstein ellipse as well. As you say, I can use extrapolate for those cases, but that does beg the question, is returning zero the best way to flag that error?
    Sheehan Olver
    That was probably a poor design decision from ages ago. The use case is for adding two functions whose domains are different. But the issue is a conflation of the support of a function with the domain, so some thought would he needed before changing it
    If it were redesigned it would probably throw an error: it doesn’t really make sense to automatically do analytic continuation while also supporting piecewise functions
    Don MacMillen
    Good to know. Thanks again.
    Hello, I'm trying to solve the Helmholtz eqn for arbitrary wavenumber, building on the example in the readme.
    using ApproxFun, Plots, LinearAlgebra
    const c₀ = 3.0*10^8
    d = Circle(0.0, 1.0, true)                         # Defines a circle
    Δ = Laplacian(d)                            # Represent the Laplacian
    f = ones(∂(d))                              # one at the boundary
    ω = Interval(0.0..10.0^9)
    k = ω/c₀
    u = \([Dirichlet(d); Δ+k*I], [f;0.];       # Solve the PDE
    surface(u)                                  # Surface plot

    I get the error 'Implement Laplacian(Laurant(:clock:), 1)'

    When looking in to the code for ApproxFun, i can find no reference to the laplacian, only a confusing macro for implementing general derivative operators.
    Where would I go to work out how to implement new Operators?

    I was also wondering if it was yet possible to build spaces of arbitrary dimension to solve 3D PDEs, possibly with extra non spatial dimensions to represent free parameters

    Sheehan Olver
    do you actually want a Disk()? That sort of existed at one point but the code is crusty. We do have a version in MultivariateOrthogonalPolynomials.jl which uses @MikaelSlevinsky’s awesome FastTransform to do function approximation on the disk, but there’s no build script for that
    For 3D, we’re starting to implement that in MultivariateOrthogonalPolynomials.jl for the cone (random yes, it’s because I’m writing a paper about the cone with Yuan Xu)
    But honestly ApproxFun needs a significant refactor before 3D can be tackled seriously: it’s possible to get it working but requires fighting hacky code the whole way, and is not amendable to high performance
    There is work behind the scenes on ContinuumArrays.jl to provide a more sound underpinning that scales to 3D, but it won’t be worked on seriously in the next 6 months or so
    If you are interested in helping with that I’m happy to talk more.
    Rodney Polkinghorne
    Hi. I'm working with the Gross-Pitaevskii Equation in two dimensions, with periodic boundary conditions, and I'm trying out the periodic parts of ApproxFun. Could someone please remake the ApproxFun manual? Apparently it's been 10 months since PeriodicInterval was updated to PeriodicSegment in the source tree, but the Latest version at github.io is that out of date.
    Rodney Polkinghorne
    This is a great package by the way. Over the years, I must have written 4 or 5 half-baked versions of parts of it.
    Sheehan Olver
    Thanks! I’m busy right now but will accept any PRs to fix the manual.
    Rodney Polkinghorne
    I think I've found the bug. The script docs/travis.sh is missing a "using Pkg". PR coming up.
    Sheehan Olver
    Rodney Polkinghorne
    There should be a metatest to check for errors when that part of the test runs.
    Sheehan Olver
    It’s possible to run the doctests automatically, I think BlockArrays.jl does this
    Rodney Polkinghorne
    Now that docs/travis.sh is working, I'm updating docs/make.jl to be consistent with the split into ApproxFunBase etc.
    I've noticed that ApproxFun doesn't reexport DomainSets. So the manual describes ProductDomain and UnionDomain, but these aren't exported by ApproxFun.
    Is this a bug or a documentation error? I.e., was the intention to export those symbols from ApproxFun, or should the manual say that you need a "using DomainSets" to access them?
    Also, there doesn't seem to be any documentation for boundary. I'll raise an issue for that.
    Sheehan Olver
    Ah, this is because these types used to be inside ApproxFun. Since these are a bit esoteric it might be better for the manual to say using DomainSets
    Rodney Polkinghorne
    Drat. The moment I fix the Travis script, they break Documenter. I'll file an issue.
    Stefanos Carlström
    Are you sure it's Documenters fault? Looks like a stack overflow on 1.2:
    Sheehan Olver
    That bug on 1.2 is already fixed in the back ports branch of Julia
    Rodney Polkinghorne
    It crashes on my desktop too, and I'm using 1.1.
    Is there a reasonable way to represent functions with discontinuities (i.e., the heaviside function) in this package? I was thinking about trying to solve an boundary value problem with an RHS of that form, but for something like H=Fun(x->(0<x)), the package returns ┌ Warning: Maximum number of coefficients 1048577 reached in constructing Fun. └ @ ApproxFunBase /Users/guardian/.julia/packages/ApproxFunBase/RLdLv/src/constructors.jl:138
    there are obvious Gibbs oscillations at the jump discontinuity
    I am trying to solve the Lane Emden equation. It's working with n as an integer but I get an error for real values
    Is there any workaround to have the code work solving non linear pde equation with real value exponent?
    MethodError: no method matching ^(::ApproxFun.DualFun{Fun{Chebyshev{Interval{:closed,:closed,Int64},Float64},Float64,Array{Float64,1}},ConstantOperator{Float64,Chebyshev{Interval{:closed,:closed,Int64},Float64}}}, ::Float64)
    Closest candidates are:
      ^(!Matched::Missing, ::Number) at missing.jl:115
      ^(!Matched::Float64, ::Float64) at math.jl:870
      ^(!Matched::Irrational{:ℯ}, ::Number) at mathconstants.jl:91
     [1] (::var"#65#66")(::ApproxFun.DualFun{Fun{Chebyshev{Interval{:closed,:closed,Int64},Float64},Float64,Array{Float64,1}},ConstantOperator{Float64,Chebyshev{Interval{:closed,:closed,Int64},Float64}}}) at ./In[49]:6
     [2] newton(::var"#65#66", ::Fun{Chebyshev{Interval{:closed,:closed,Int64},Float64},Float64,Array{Float64,1}}; maxiterations::Int64, tolerance::Float64) at /projects/d1d068b5-3a9d-4e16-9252-52734dea2c8e/.julia/packages/ApproxFun/IC3js/src/Extras/autodifferentiation.jl:98
     [3] newton(::Function, ::Fun{Chebyshev{Interval{:closed,:closed,Int64},Float64},Float64,Array{Float64,1}}) at /projects/d1d068b5-3a9d-4e16-9252-52734dea2c8e/.julia/packages/ApproxFun/IC3js/src/Extras/autodifferentiation.jl:95
     [4] top-level scope at In[49]:7
    x  = Fun(identity, 0..10)
    n = 2.3
    u₀ = 0.0x # initial guess
    N = u -> [u'(0), u(0)-1, x*u'' + 2*u' + x*u^n]
    u = newton(N, u₀) # perform Newton iteration in function space
    Hi All, is this a good place to ask a questions about Using ApproxFun for dynamic programming ?
    Could someone please comment on the ease of using ApproxFun.jl for the simulation of a 1D and 2D Fokker-Planck equations (modeling e.g. particle distributions)? In essence, I want to simulate an advection-diffusion equation with variable advection and diffusion coefficients (nonconstant over the space domain).
    Thank you!
    PS: sorry if this is not the right place for such questions.