Comments (8)
Sorry it took me a while to get to this. Remember that "u" here is the fluid velocity, not the fluid position, so there is no need to have u_dot there. The kinetic energy in the fluid is just
from pysindy.
@Jacob-Stevens-Haas I did push my latest version a few days ago but I did not make structural change at all -- just played with those examples you have already seen a bit more for paper revisions. But can you share some of the major conflicts you have now? We can actually meet on campus if you are available this or next week to talk about this so that you can show me directly.
edited:
the conflict in the example you mentioned for checking symmetries of all those tensors is because a new tensor is introduced so we changed the algorithm a little bit. And it is exactly what you found -- the old version only works when we have those constraints. As what I replied in the other thread, we were trying to get rid of the make_constraints()
so we need to rewrite this part.
from pysindy.
As an addition, the constraints made by example 8's make_constraints()
appear to be in neither in "row" or "target" format, since reorder_constraints(constraint_lhs, 2, "row")
and reorder_constraints(constraint_lhs, 2, "target")
both change it.
from pysindy.
@Jacob-Stevens-Haas there is a small error in the constraints -- but I think we fixed this on @MPeng5 's trapping branch of the pysindy code and have been meaning to start a pull request to get that and some new stuff added. However, we think this was for dimension > 3 systems and it left the trapping example 8 virtually unchanged (and working a bit better fortunately!).
For the example above, there is no error I believe. It looks incorrect because you are not using the custom ordered polynomial that we use in the trapping method. This was a stupid thing that I implemented the constraints in this way, but basically it is expecting a Polynomial Library (a custom library of polynomial terms) that looks like [x, y, xy, x^2, y^2]. Then the constraints are correct:
For instance, the first row is saying the x^2 term should vanish in the 1st equation for x_dot (assuming I'm reading that off correctly), second constraint says the y^2 term should vanish in the equation for y_dot, third constraint says xy term in y_dot must match the y^2 term in x_dot, and fourth constraint says xy term in x_dot must match the x^2 term in y_dot. These are all correct with the reordered library!
For the energy, it is just E = 0.5 * u^2 and plug in Equation (2) and use the orthogonality of the spatial modes and integrate over the volume to get K = 0.5 a^2 as the total time dependent part of the energy in the fluid. Now we are interested dK/dt = a * a_dot and we do not assume dK/dt = 0. We assume a-priori that the dynamics have vanishing cubic contributions to dK/dt, i.e. dK/dt = C_ia_i + L_{ij}a_ia_j + Q_{ijk}a_ia_ja_k, and only the last term that is cubic vanishes.
from pysindy.
Ohhh, that makes sense if the terms are flattened in fortran order/interspersed, like if
For the energy, it is just E = 0.5 * u^2 and plug in Equation (2) and use the orthogonality of the spatial modes and integrate over the volume to get K = 0.5 a^2 as the total time dependent part of the energy in the fluid. Now we are interested dK/dt = a * a_dot and we do not assume dK/dt = 0. We assume a-priori that the dynamics have vanishing cubic contributions to dK/dt, i.e. dK/dt = C_ia_i + L_{ij}a_ia_j + Q_{ijk}a_ia_ja_k, and only the last term that is cubic vanishes.
I can follow that derivation, but I guess I'm unsure why for PDEs we use
I obviously have been trying to use trapping recently, and I made a PR to clean up the code and reduce the number of lines so it was clearer what was the methods did. I don't think there are significant conflicts in functionality with @MPeng5's branch, but there are some cases where I refactored a function to be clearer while y'all expanded the functionality in a way that's algorithmically compatible but would show up as a git conflict. Example: yous, mine, master. It's tricky to tell because the "compare branches" doesn't show the git conflicts, and because there might be more issues if @MPeng5 or you have commits more recent than the August 17 one on git. For instance, it doesn't show that the make_constraint()
function was added to pysindy.
I'm not at all wedded to my code, but I would like to be able to develop and work on trapping asynchronously. My spidey sense is that this will be a difficult PR and we should start working through any structural changes sooner rather than later. Could you guys at least push your most recent commits so that I can see what you're working on?
from pysindy.
Remember that "u" here is the fluid velocity
🤦♂️ Of course. That makes sense.
Hey @MPeng5 , thanks for following up! I'd love to talk about this but I'm not on campus (in London until April). We'll have to Zoom, if that's OK? What's your email?
the conflict in the example you mentioned for checking symmetries of all those tensors is because a new tensor is introduced so we changed the algorithm a little bit
Yeah, it seems simple enough. New tensor, PT, that appears to use the same checks as PQ.
But can you share some of the major conflicts you have now?
Firstly, my edits to make_constraints()
are in trapping-constraints
, and make_constraints()
isn't part of trapping_sr3.py in either my refactor in trapping-helper
or your work in trapping-extended
. So #437 should be fine to review and merge independently.
Broadly, the conflicts between trapping-helper
and trapping-extended
are where I found a way to condense the code and make it more readable, whereas you added functionality in the old style (like _check_P_matrix
). So my recommended way forwards is to review/merge #435, pull it into trapping-extended
, then create a PR for trapping-extended
.
- all
__init__()
validation is now done in__post_init_guard()
, which is also called byset_params()
, so that we follow the scikit-learn API TrappingSR3
is made a subclass ofConstrainedSR3
. This removes a lot of cvxpy code fromTrappingSR3
, since it can just inherit those methods.- The main implication for conflicts with
trapping-extended
is that conditional calls to cvxpy are extracted into their own functions, and conditional calls to other solution methods are also extracted for consistency. In other words, there's the main iteration loop -> a function to update eitherm
orcoef
-> preliminary steps, plus a function to solve an optimization problem (e.g. calling_update_coef_cvxpy()
, inherited from superclass). - It also looks like you removed the
relaxed_optim
option, and thus thesolve_direct
methods? - Some variable names are changed to be more readable, most significantly
m -> trap_ctr
,r -> n_tgts
,N -> n_features
_set_Ptensors()
, like_check_P_matrix()
, was condensed and made more readable.- Other things, like sorting the docstring to match the args might be git conflicts but aren't real conflicts.
It might also help to merge master
into trapping-extended
first to get caught up on the non-trapping changes to SINDy first.
from pysindy.
@MPeng5 why don't you also open a PR for trapping-extended
so it's possible to attach questions to specific lines?
from pysindy.
@Jacob-Stevens-Haas Of course! Totally forgot Nathan brought a bunch of people to London and you are one of them. Let's try to meet next week on zoom and my email is [email protected].
from pysindy.
Related Issues (20)
- [BUG] Multiple trajectories raises a ValueError HOT 2
- Allow explicit control of randomness for ensembling
- [BUG] cannot import name 'enzyme' HOT 1
- Library truncation issue in E-SINDy HOT 1
- Setting up a model identification in real life data HOT 11
- [BUG] Remove `interaction_only` arg from PDELibrary
- Bayesian Sindy HOT 2
- [BUG] TypeError for keyword normalize when instantiating optimizer. HOT 1
- Documentation for Handling Trigonometric Functions in SINDy-PI Library Functions HOT 1
- Be explicit about CVXPY solvers
- polynomial library to include second order derivative HOT 2
- Unsure on the correct use of pySINDy
- LinearRegression unknown keyword normalize HOT 5
- Implementation of graph data HOT 7
- Issue in plotting the graph using model.simulate HOT 1
- Total freedom in library functions with CustomLibrary HOT 1
- SINDy-PI for a system of ODEs
- simulating error(overflow) when expanded to the third order HOT 3
- [BUG] A lot of issues with the bayesian implementation (UQ-SINDy) HOT 3
- [BUG] No consistency in model.fit() HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pysindy.