Recursive Array Tools Notebook

[sumedha-k]

No description provided.

[sumedha-k]

@aarmey here's the notebook I mentioned in lab meeting today

[codecov]

Codecov Report

Merging #281 (3bce3cb) into master (b43488c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #281   +/-   ##
=======================================
  Coverage   66.74%   66.74%           
=======================================
  Files           7        7           
  Lines         451      451           
=======================================
  Hits          301      301           
  Misses        150      150           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b43488c...811211b. Read the comment docs.

[aarmey]

@sumedha-k I don't see the code you showed me?

[sumedha-k]

@aarmey sorry about that, just updated it

[aarmey]

I think I figured out the issue—take a look at the first cell I updated. The named elements in an SLVector just need to be single elements, not vectors.

[sumedha-k]

@aarmey I included the information in recursive.ipynb in the last three cells.

[aarmey]

I'm not sure I see the problem? You show that you can access arrPart.x[1].expression, but it doesn't work with arrPart2.x[1].expression because you didn't build it with labelled arrays. Perhaps you could add something you expect to work but doesn't? You're right that the ArrayPartition subarrays can't have their own labels, but I think we can live with that.

[aarmey]

Oh, I see the issue. We do use structs as essentially labeled ArrayPartitions. Let me do a little digging...

[aarmey]

I think I have an alternative approach for plugging this into ModelingToolkit. The TAMrates struct is really not the problem—it's the need to have an AbstractVector type at the ODE function interface. Do you see how to write a function that takes in a TAMrates and outputs a vector with all the values flattened out, and then vice versa? In other words, concatenate all the values in the struct to one vector? If we have these conversion functions I think we can accomplish the same thing without changing a ton of code.

[sumedha-k]

Sounds good, should I add these function to the types.jl file or should I create a new file?

[aarmey]

Yes, this can go in types.jl

[sumedha-k]

@aarmey I couldn't figure out the source of this build error. It appears to be a result of the most recent merge commit.

[aarmey]

Get rid of the changes you made to the Manifest file and I bet it'll work.

[sumedha-k]

@aarmey I deleted the whole Manifest file and copied the one in the master branch but I'm still getting the error

[aarmey]

@sumedha-k you need an end on the end of this ifelse block.