## #3108 closed defect (fixed)

# Divide by zero in PlanarLoops_analytic

Reported by: | Christian Andersson | Owned by: | jsten |
---|---|---|---|

Priority: | major | Milestone: | 1.12.x |

Component: | CodeGen/C | Version: | trunk |

Keywords: | #2585. | Cc: |

### Description

There is a problem in the MBS model PlanarLoops_analytic with a divide by zero. The problem is due to that the parameter jointRRR2.jointUSR.rod1.rodLength does not get a value. The parameter is defined as (seen from the transformed model)

parameter Modelica.SIunits.Distance jointRRR2.jointUSR.rod1.rodLength(fixed = false,start = Modelica.Math.Vectors.length({0.5, 0.09999999999999998, 0.0})) "Length of rod (distance between origin of frame_a and origin

There is also an initial equation for the parameter

jointRRR2.jointUSR.rod1.rodLength = Modelica.Math.Vectors.length({0.5, 0.09999999999999998, 0.0});

However, when looking at the generated C-code there is no assignment to this parameter. Not in the parameter evaluations or in the initialization method and thus the parameter has the value zero which is incorrect and leads to problems.

This is needed for #2585.

### Change History (7)

### comment:1 Changed 6 years ago by

### comment:2 Changed 6 years ago by

The model currently fails with a unmatchable system where the unmatched variables are fixed=false parameters with evaluate = true and an initial euqation.

This causes problems in the compiler since we inline the result in the initial equations. For example the following model:

model C parameter Real p(fixed=false) annotation (Evaluate=true); initial equation p = 1; end C;

There are two possible solutions as I see it:

- Use the initial equation to calculate the value of p, is this always possible?
- Give a warning saying that evaluation of parameters with initial equation is ignored

### comment:3 Changed 6 years ago by

changeset:5418

Fixed so that parameters with fixed=false ignores evaluate annotation.

Still need to add a compliance error when fixed=false parameters are marked as structural parameters

### comment:4 Changed 6 years ago by

Resolution: | → fixed |
---|---|

Status: | new → closed |

changeset:5419

Added a compliance error for fixed=false parameters that are marked as structural.

### comment:5 Changed 6 years ago by

Resolution: | fixed |
---|---|

Status: | closed → reopened |

The following model causes problems with the latest commit:

model C model A parameter Real p = 2 annotation(Evaluate=true); end A; A a(p=p); parameter Real p(fixed=false) annotation (Evaluate=true); initial equation p = 1; end C;

### comment:6 Changed 6 years ago by

Resolution: | → fixed |
---|---|

Status: | reopened → closed |

changeset:5421

Fixed tricky fixed=false and evaluate=true case.

**Note:**See TracTickets for help on using tickets.

changeset:5331

Parameters that depends on parameters with fixed=false are now also marked with fixed=false.

This is only a partial fix since that model contains other problems (initial system with unmatched equations).