check for `Symbolics.VariableSource => :Parameter` in `isparameter`

[oameye]

I have the problem that my symbols are detected as variables instead of parameters. This is due they not have the MTKVariableTypeCtx metadata information. I could set by:

SymbolicUtils.setmetadata(s,MTK.MTKVariableTypeCtx,MTK.PARAMETER)

However, I would like my package to be independent of the ModelingToolkit dependency. I was wondering if in the isparameter function in

ModelingToolkit.jl/src/parameters.jl

Lines 7 to 27 in 60c95b9

	function isparameter(x)
	x = unwrap(x)
	if x isa Symbolic && (varT = getvariabletype(x, nothing)) !== nothing
	return varT === PARAMETER
	#TODO: Delete this branch
	elseif x isa Symbolic && Symbolics.getparent(x, false) !== false
	p = Symbolics.getparent(x)
	isparameter(p) ||
	(hasmetadata(p, Symbolics.VariableSource) &&
	getmetadata(p, Symbolics.VariableSource)[1] == :parameters)
	elseif iscall(x) && operation(x) isa Symbolic
	varT === PARAMETER || isparameter(operation(x))
	elseif iscall(x) && operation(x) == (getindex)
	isparameter(arguments(x)[1])
	elseif x isa Symbolic
	varT === PARAMETER
	else
	false
	end
	end

we could add an extra case which checks the Symbolics.VariableSource metadata outside of the symbolic having a parent. That way symbolic parameters that were not made with MTK.@parameters can still be used in ModelingToolkit.

[SebastianM-C]

Would an extension for MTK help your package?

[oameye]

@SebastianM-C mmm, not really. I am in the progress of extracting the quantum symbolic algebra in QuantumCumulants.jl to implement another quantum perturbative expansion with it. I would like the quantum symbolics algebra package to be independent of MTK. The only thing holding me back is that I eventually need the symbolics to be compatible with MTK. Which for now it means I need: MTK.MTKVariableTypeCtx and MTK.PARAMETER.

To be more exact, QuantumCumulants.jl define @CNumber and @RNumber to distinguish between real and complex parameters within the package. When later converting the quantum algebra to ODEs (taking cumulants), we simulate it by converting to ODESystem. Implementing a extension would mean I would have to reparse all the symbols to add the MTK.MTKVariableTypeCtx to the parameters.

As Symbolics.VariableSource is already checked for indexed symbolics, would it be so weird to also check it for non-indexed symbolics?

[oameye]

It would allow system created with Symbolics.jl to also work in MTK. Would that not be positive?

[AayushSabharwal]

This is not something we want to do, in some sense specifically for this reason. If you're not using MTK.@parameters to create your parameters, there is no guarantee MTK will consider them as parameters. Down the line, MTK may change what sort of metadata parameters must have. If you don't use MTK.@parameters, your symbolic variables won't have this metadata and won't be MTK compatible. This is equally an abstraction for MTK and a convenience for users.

ModelingToolkit@10 will stop relying on metadata to identify parameters during structural simplification. That should enable you to pass the symbolic variables to the correct argument of ODESystem (or System in v10) and have them be recognized as parameters regardless of metadata.

[ChrisRackauckas]

Yes the bigger change here is that D(x) ~ 0 can be considered a parameter, or even D(x(t)) ~ f(t). Thus the plan down the line is to treat anything that @variables p as a parameter, since D(p) ~ 0 since it's not time-dependent, and so it doesn't need to be an evolution equation. We will do some things so that it's as non-breaking as possible to people using the MTK interfaces, but indeed to do the next step of compiler passes we will need to be able to move things between unknowns, parameters, discretes, etc. as the compiler feels necessary, so instead everything is about "what is the variable dependent on and what equations are it in", and from that the compiler may symbolically get the analytical solution and move something to be a parameter. The interfaces are made so "it doesn't matter".

So, the right solution here might be to just wait for those things in v10.

[ChrisRackauckas]

Closing as not planned, since the coming changes to the compiler should make this not required.

[oameye]

Okay, very interesting. Thanks for all the information. I will wait patiently for the next breaking release :)