Error in the Sparsity section of the SumofSquare package


I am using Julia 1.8.0 in windows 10, and I have updated all my packages. I want to implement the example in the sparsity section of the SumofSquare package (Term sparsity · SumOfSquares).

when I run the following code:

using SumOfSquares

I get the error:
LoadError: type DataType has no field NoPattern

in expression starting at untitled-7a4e1ebf8fcbd16f45516544e1a037c0:2

getproperty(x::Type, f::Symbol) at Base.jl:33

top-level scope at untitled-7a4e1ebf8fcbd16f45516544e1a037c0:2

eval at boot.jl:368 [inlined]

include_string(mapexpr::typeof(identity), mod::Module, code::String, filename::String) at loading.jl:1428

or if I run:

using SumOfSquares

I get the error:

LoadError: type DataType has no field Monomial

in expression starting at untitled-7a4e1ebf8fcbd16f45516544e1a037c0:2

getproperty(x::Type, f::Symbol) at Base.jl:33

top-level scope at untitled-7a4e1ebf8fcbd16f45516544e1a037c0:2

eval at boot.jl:368 [inlined]

include_string(mapexpr::typeof(identity), mod::Module, code::String, filename::String) at loading.jl:1428


It seems the SumOfSquare package has not been fully added. This is because some of the objects of this package are not defined. For example, after running


I get
ERROR: UndefVarError: Symmetry not defined
or after runnign


I get
ERROR: UndefVarError: ChordalExtensionGraph not defined

and many more.

You seem to have a variable called Sparsity that’s shadowing the Sparsity (sub)module within SumOfSquares.

Do you have a Sparsity = line somewhere in your code? Maybe you had something like that earlier in the REPL/notebook; you can try restarting Julia and see if that fixes the issue.

(You can also run @which Sparsity, typeof(Sparsity), and display(Sparsity) to confirm which Sparsity you’re accessing.)

Thank you for your answer.

No there is nothing like

Sparsity =     

before that.
The following code

using SumOfSquares

should work itself because I tested it on another computer and it worked.

If I run

@which Sparsity

I get

If I run


I get

However, if I run


I get
ERROR: UndefVarError: NoPattern not defined

In that case, you must have a version of SumOfSquares that’s below v0.5 i.e. 0.4.7 or earlier. You mentioned

in the original post, but there may be other packages that are keeping SumOfSquares from actually updating to a recent version. Can you post the output of import Pkg; Pkg.status() here?

I uninstalled and then installed Julia again. It still doesn’t work.
This is the packages status:

Status `C:\Users\raven\.julia\environments\v1.8\Project.toml`
[c52e3926] Atom v0.12.38
⌃ [0a46da34] CSDP v0.7.1
⌃ [7c1d4256] DynamicPolynomials v0.3.21
⌃ [60bf3e95] GLPK v0.14.14
⌃ [b99e6be6] Hypatia v0.5.3
⌅ [4076af6c] JuMP v0.21.10
  [e5e0dc1b] Juno v0.8.4
⌅ [b8f27783] MathOptInterface v0.9.22
⌅ [6405355b] Mosek v1.2.3
⌃ [1ec41992] MosekTools v0.9.4
⌃ [be282fd4] MultivariateBases v0.1.3
⌃ [f4abf1af] MultivariateMoments v0.3.6
⌅ [102ac46a] MultivariatePolynomials v0.3.18
⌅ [d8a4904e] MutableArithmetics v0.2.22
  [8314cec4] PGFPlotsX v1.5.1
  [8bc5a954] PermutationGroups v0.3.2
  [f0f68f2c] PlotlyJS v0.18.8
  [91a5bcdd] Plots v1.33.0
⌅ [ddf597a6] PolyJuMP v0.4.3
  [f27b6e38] Polynomials v3.2.0
⌃ [8e049039] SemialgebraicSets v0.2.3
⌃ [4b9e565b] SumOfSquares v0.4.6
  [858aa9a9] SymbolicWedderburn v0.3.0
  [81648402] TSSOS v1.0.0 ``
⌃ [afbbf031] TypedPolynomials v0.2.12
  [37e2e46d] LinearAlgebra
  [de0858da] Printf
Info Packages marked with ⌃ and ⌅ have new versions available, but those with ⌅             
cannot be upgraded. To see why use `status --outdated`

I update the SumOfSquares package and I get:

    Updating registry at `C:\Users\raven\.julia\registries\General.toml`
   No Changes to `C:\Users\raven\.julia\environments\v1.8\Project.toml`
   No Changes to `C:\Users\raven\.julia\environments\v1.8\Manifest.toml`

After updating, the version of the SumOfSquare package is still v0.4.6
I tried to uninstall it completely, but, after uninstallation, there are many things related to Julia which are left. So I am wondering if I can delete everything related to Julia and then install it again, whether it can work or not. Do you know how I can delete Julia that way? or Do you have a better way?

Let me also mention something. Before updating Julia’s packages “Symmetry” was working, and only “NoPattern” was undefined. However, after updating the packages, both of them are undefined now. It seems updating causes some restrictions on accessing some functions.

Thank you.

The ^ at the beginning means that SumOfSquares can be updated, so it’s bizarre that updating it didn’t change anything. Can you mention the exact command you used to update SumOfSquares, just to be sure?

Reinstalling Julia wouldn’t help with this issue at all, since it’s to do with this particular set of packages rather than with Julia itself. So just fixing it using the package manager Pkg would be enough, we just have to figure out where which fix is needed.

One source of the issue is that you have all the packages installed in the default project environment C:\Users\raven\.julia\environments\v1.8\Project.toml itself. Which of these packages do you need for this current code that your’re trying to run? If you only need SumOfSquares, for eg., you can run

import Pkg
Pkg.activate("SumOfSquaresTutorial", shared = true)
using SumOfSquares

to have just that package in a new project environment. In this case, there’s no chance of version conflicts, so you should automatically get the latest version of the package.

Some more information about project environments is in the Pkg documentation page.

1 Like

I raised this through Two types of blocked updates/upgrades of packages in 1.8. I am afraid I am not any wiser after that discussion though.

To update SumOfSquares, I used ] to go to the pkg, and then I typed

 update SumOfSquares

In order not to have all the packages installed in the default project environment, what should I do?

I used it and it worked. However, it worked only one time. If I run this code again, some of the objects are still undefined.

After you’ve run this once, you can start Julia as julia --project=@SumOfSquaresTutorial and then run using SumOfSquares once Julia starts (the other steps aren’t necessary after the first time). Then the correct version will be loaded and the code from the tutorial should work.

You may have seen that I asked a question in that thread and got an answer, but to be honest I’m also not much wiser after the answer - my understanding from it is that it’s apparently a tricky, intricate problem, and these indicators are only supposed to be a “best effort” measure. Wish that was communicated more clearly when the feature was announced and documented, to avoid confusions like this.

1 Like

Thank you.

From now on, I create different environments for different projects. Having said that, how can I clear the default project environment or how can I make it like the first day of using Julia? If I simply remove packages with

 Pkg.rm("name of that package")

does that work? Or do I need to do something more?

Moreover, I may need other packages in addition to the SumOfSquares package for my project. In that case, the only thing that I can do is to hope that the packages required for the project have not conflict with each other, or can I do more?

Yes. You can also pass in a vector of package names like Pkg.rm(["Atom", "CSDP", "DynamicPolynomials"]) to remove all of them at once.

You can also go into the “package mode” by pressing ] in the REPL. Once you see the (@v1.8) pkg> prompt, you can type rm Atom CSDP DynamicPolynomials and whatever else. Works the same as Pkg.rm(...) call, just slightly more convenient syntax.

Good! Just so you know, the more common way of creating environments for projects is to start Julia from the project’s main folder, and within Julia do Pkg.activate("."). The difference between this and the previous one is that because there’s no shared = true argument, this project environment is created locally in this project’s own folder. In comparison, the shared environments are created in a common folder that Julia itself creates. I suggested that before because I wasn’t sure where you were running Julia from, and wanted to avoid that extra source of confusion.

From now on, when creating project environments for new projects, you can use this non-shared local format. Using either Pkg.activate(".") or ]activate .
Once you’ve done that, when starting Julia, if you’re in the project’s folder, you can just run julia --project, and Julia will know to use the project environment that’s in the current directory.

Yes. Package conflicts, especially to this extent of holding it back by several versions, are not very common, so it’s not too much of a problem.
It’s just that when you have many packages, especially unrelated ones and ones that are not actively used, it’s likely that one or two of them happen to be not actively maintained packages, that are depending on very old versions. Those can hold everything else back. Often, there are better alternatives to those packages that can take their place instead, with more up to date version compatibilities.

That is a comprehensive answer. Thank you very much.