fix: change variable defaults to guesses

[avinashresearch1]

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

Add any other context about the problem here.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 31 lines in your changes missing coverage. Please review.

Project coverage is 0.00%. Comparing base (3a8fb0a) to head (6e2af95).
Report is 7 commits behind head on main.

❗ Current head 6e2af95 differs from pull request most recent head f000b3d

Please upload reports for the commit f000b3d to get more accurate results.

Files	Patch %	Lines
src/Blocks/utils.jl	0.00%	29 Missing ⚠️
src/Blocks/continuous.jl	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #281       +/-   ##
==========================================
- Coverage   61.48%   0.00%   -61.49%     
==========================================
  Files          46      32       -14     
  Lines        1472    1657      +185     
==========================================
- Hits          905       0      -905     
- Misses        567    1657     +1090     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[avinashresearch1]

@ven-k I'm a little confused as to what is causing the test failure, its from the code below:

@mtkmodel SISO begin
           @parameters begin
               u_start = 0.0
               y_start = 0.0
           end
           @variables begin
               u(t), [guess = u_start, description = "Input of SISO system"]
               y(t), [guess = y_start, description = "Output of SISO system"]
           end
           @components begin
               input = RealInput(u_start = u_start)
               output = RealOutput(u_start = y_start)
           end
           @equations begin
               u ~ input.u
               y ~ output.u
           end
       end

its due to guess = u_start, not sure why it says u_start not defined when I'm trying to use the one in the params (I'm not extremely familiar with the @mtkmodel syntax).

[avinashresearch1]

@ven-k I'm a little confused as to what is causing the test failure, its from the code below:

@mtkmodel SISO begin
           @parameters begin
               u_start = 0.0
               y_start = 0.0
           end
           @variables begin
               u(t), [guess = u_start, description = "Input of SISO system"]
               y(t), [guess = y_start, description = "Output of SISO system"]
           end
           @components begin
               input = RealInput(u_start = u_start)
               output = RealOutput(u_start = y_start)
           end
           @equations begin
               u ~ input.u
               y ~ output.u
           end
       end

its due to guess = u_start, not sure why it says u_start not defined when I'm trying to use the one in the params (I'm not extremely familiar with the @mtkmodel syntax).

This requires: SciML/ModelingToolkit.jl#2501

[avinashresearch1]

Rebased after @AayushSabharwal 's changes #291

[avinashresearch1]

@baggepinnen request for review

[SebastianM-C]

I also had the same suggestion in #292, but #292 (comment)

[baggepinnen]

Integrators always start at zero though?

Most of the time this is what users want, but it is occasionally useful to have the system solve for an integrator value that makes an initial control signal have a particular value to avoid initial transients, so forcing the user to specify the initial state explicitly might not be too bad

[baggepinnen]

I guess the user can not easily remove a default value that has been specified in the library? If they cannot remove the value, we must not provide it since then it cannot be solved for

[baggepinnen]

Since we now have the capability to remove a default, the explicit state variables, like those in Integrator, Derivative, FirstOrder, SecondOrder should keep their defaults, but y,u in SISO etc. should not

[avinashresearch1]

Yes, I am probably going to make a new PR, since almost everything in this is not correct :(

[avinashresearch1]

@ChrisRackauckas We can probably close this without merging since this PR has more incorrect than correct things, I'll make a new PR for the things that I would like to fix and the docs.

[ChrisRackauckas]

okay

[ChrisRackauckas]

Where is this at?