JuliaHub raises $65m Series B and launches Dyad 3.0

Congratulations to the whole team!

Here’s hoping that 0.1% of the funding goes towards completing date axis support for Makie :smiley:

remind me what’s still missing :sweat_smile:

Congratulations. I am still optimistic that we can overcome the two language problem. Together.

Probably one for another thread, but my main gripe with it at the moment is that I can’t add vlines to date axes:

lines(Date(2000):Year(1):Date(2010), rand(11))
vlines!(Date(2005))

errors during some conversion attempt.

Just to bandwagon, are there any issues on unitful heatmaps (specifically for the zvals/colorbar values) that we can follow, maybe in relation to Improve dim converts recipe compatibility, usability by ffreyer · Pull Request #5323 · MakieOrg/Makie.jl · GitHub or Breaking release 0.25 by ffreyer · Pull Request #5484 · MakieOrg/Makie.jl · GitHub?

Are 65 thousands dollars necessary to fix that ? :sweat_smile:

I’m not sure dates are something we use a lot in plots :sweat_smile:, but I will note that the 4th most active Makie contributors, @asinghvi17, is one of the members on the Dyad team and some of our product areas like Multibody use Makie, so there is a good amount that gets upstreamed here. In particular, SciML is starting to use Makie recipes (at least as implemented by Anshul) and so we’ll be relying on and improving that along the way. Just thought I’d mention how this all ties back into open source!

Dear Christopher, I hope you do not mind and I hope this message finds you well. If I may ask, whom do you currently represent? I recall that a few years ago, shortly after I joined the community, you kindly suggested that I reach out to you. At that time, my understanding was that I would be contacting the MIT researcher. However, I soon realized this was likely not the case. I would be grateful if you could clarify your current role and affiliation. Thank you in advance for your time.

Units for vlines, hlines, heatmap are all fixed in #5323 / Makie 0.25. Almost all plots should be fixed after that.

I represent Chris :sweat_smile:. The positions are all concurrent. I am still a research affiliate at MIT, doing work every week with the students to publish research in numerical methods and scientific machine learning. I am the VP of Modeling and Simulation at JuliaHub, leading the Dyad team to put a commercial modeling software out. I also have affiliations with Neuroblox and PumasAI which are other transitions of MIT Julia Lab / Julia’s open source into industrial spaces. Then there’s also just everything around the SciML Open Source Software Organization, which is a non-profit around the open source software since not all open source software is research related (probably only half :sweat_smile:).

So

Nope, you’re still contacting the MIT researcher. Note that none of my affiliations has changed since 2021, so this has all been the same the last 5 years. Still averaging 20 publications or so a year, so it’s all still current and ongoing. Just many many things going on.

Generally the triage is that, if you have an open source issue, then please open an issue. That’s the MIT / open source hat, I do all of that work publicly. Share your MWE on Github, and I’ll work on it, discuss in open Slack channels, etc. All of the ongoing work for publications and such is just out there being collaboratively worked on as part of the org. If you have a secret IP that you cannot share, then it’s not in the MIT / open source bucket. If it’s pharma, it’s the PumasAI bucket. Neuroscience, Neuroblox bucket. Anything else industrial, JuliaHub bucket. FWIW, I also karaoke DJ at night, many times while on Discourse.

But if you want help on private IP directly to me, I do get around to it sometimes. But do note that at this point, the open source community is large enough that I get around 30 or so emails a day of private models / ODEs to dig around in, and these days it’s difficult to keep up with that amount. I try to respond to each email in some way, but sometimes it can be quite late. If you want priority, then go through JuliaHub as whatever is there goes to the top of the list. Otherwise, I always note for folks to post their model and question publicly, like to this Discourse, as the priority order is commerical engagements → public work → everything else. The commercial stuff is on deadlines while the MIT stuff :man_shrugging: if it takes 5 years to publish no one’s counting (but generally I’ll respond to everything online :sweat_smile:)

There’s just a ton of requests and lots going on. We need to really grow the team of developers and researchers and really share the load more there. This system is designed exactly for that: to continually help get more people into the Julia ecosystem full time.

So if I missed something, totally sorry and hopefully by growing the team and lab less will be missed.

It looks like there are many potential conflicts of interest, I’m glad I stayed away since our initial direct contact.

@asinghvi17 is one of the most helpful people I met in the Julia community, especially around makie and documenter. Tell his boss he deserves a raise!

Right, so unitful axes for heatmaps work beautifully now, thank you! I was wondering more if plotting a unitful matrix was also a possibility? I currently seem to get the following error when I try on your branch:

julia> using CairoMakie, DynamicQuantities

julia> heatmap(rand(3, 4)u"m")
ERROR: ArgumentError:
Conversion failed for Heatmap (With conversion trait CellGrid()) with args:
    Tuple{QuantityArray{Float64, 2, Dimensions{FRInt32}, Quantity{Float64, Dimensions{FRInt32}}, Matrix{Float64}}}
Got converted to:
    Tuple{QuantityArray{Float64, 2, Dimensions{FRInt32}, Quantity{Float64, Dimensions{FRInt32}}, Matrix{Float64}}}
Heatmap requires to convert to argument types
    Tuple{Union{AbstractVector{T} where T<:Real, Makie.EndPoints, AbstractMatrix{T} where T<:Real}, Union{AbstractVector{T} where T<:Real, Makie.EndPoints, AbstractMatrix{T} where T<:Real}, AbstractMatrix{<:Union{Float32, Float64, ColorTypes.Colorant}}},
which convert_arguments didn't succeed in. To fix this overload convert_arguments(P, args...) for Type{<:Heatmap} or CellGrid() and return an object of the correct type.
(Dim converts were not applied. This happens if `space = data` is not in data space or if the target type of the conversion is reachable without dim converts.)


Stacktrace:
 [1] argument_error(PTrait::CellGrid, P::Type, attr::ComputePipeline.ComputeGraph, user_kw::Dict{…}, converted::Tuple{…})
   @ Makie ~/.julia/packages/Makie/qX9Ep/src/compute-plots.jl:1052
 [2] (Heatmap)(user_args::Tuple{QuantityArray{Float64, 2, Dimensions{…}, Quantity{…}, Matrix{…}}}, user_attributes::Dict{Symbol, Any})
   @ Makie ~/.julia/packages/Makie/qX9Ep/src/compute-plots.jl:1116
 [3] _create_plot(F::Function, attributes::Dict{Symbol, Any}, args::QuantityArray{Float64, 2, Dimensions{…}, Quantity{…}, Matrix{…}})
   @ Makie ~/.julia/packages/Makie/qX9Ep/src/figureplotting.jl:335
 [4] #heatmap#54
   @ ~/.julia/packages/Makie/qX9Ep/src/recipes.jl:571 [inlined]
 [5] heatmap(args::QuantityArray{Float64, 2, Dimensions{FRInt32}, Quantity{Float64, Dimensions{FRInt32}}, Matrix{Float64}})
   @ Makie ~/.julia/packages/Makie/qX9Ep/src/recipes.jl:569
 [6] top-level scope
   @ REPL[2]:1
Some type information was truncated. Use `show(err)` to see complete types.

But maybe I am just setting it up incorrectly? Here is how I am adding the dev packages:

Pkg.add([
    Pkg.PackageSpec(;
        url = "https://github.com/MakieOrg/Makie.jl",
        subdir = "Makie",
        rev = "ff/breaking-0.25",
        ),
    Pkg.PackageSpec(;
        url = "https://github.com/MakieOrg/Makie.jl",
        subdir = "ComputePipeline",
        rev = "ff/breaking-0.25",
    ),
    Pkg.PackageSpec(;
        url = "https://github.com/MakieOrg/Makie.jl",
        subdir = "CairoMakie",
        rev = "ff/breaking-0.25",
    ),
])

The hope would then be to add a colorbar to this plot with the correct units

You are quite hostile in your responses considering Christopher was kind enough to answer your question in detail, while being forthcoming and honest.

I am happy that I don’t have to talk to you in person - not that nice to hear right?

Jokes aside, sure we would be able to have fun in person :slight_smile:

Kind regards

As a clueless reader, I have no idea why random cryptic complaints just pop up without any context explained to a general audience of this public forum.

I don’t think @j_u was hostile in his response. He was direct and respectful.

Probably the accumulation of unresolved issues related to Julia’s governance model. Search for “governance model” in this forum to learn more. And try to continue this conversation in a separate thread if possible.

No that’s expected to not work. And I’m not sure how that would fit into the dim converts scheme either. The idea with them is that the first plot can set a unit for, say, the x dimension and other plots can then see that and convert accordingly (or error if the units are incompatible). The matrix of a heatmap doesn’t relate to other plots like this, so it’s just skipped.

Yeah, nothing personal, Christopher, really. P.S. I’m sorry for interrupting the discussion @nilshg,
completely unintentional. By the way, to be honest, while the latest round in absolute terms looks
significant, relative to the previous one, it seems to be a rather modest increase.

Thanks for getting back to me, Frederic. Right, so that is why I was asking if there was any work / issue related to this, since it had to do with unit handling. Totally no worries if not, just wanted to make sure I wasn’t duplicating work for y’all if I was to open up an issue on GitHub to track things and maybe work on them. Thanks again for these awesome updates, I’ll stop detouring the thread here now, haha

Update: Got a draft PR going here with this functionality now: feat: Support matrix data with units by icweaver · Pull Request #5623 · MakieOrg/Makie.jl · GitHub