{"action":"created","issue":{"url":"https://api.github.com/repos/opensim-org/opensim-core/issues/1225","repository_url":"https://api.github.com/repos/opensim-org/opensim-core","labels_url":"https://api.github.com/repos/opensim-org/opensim-core/issues/1225/labels{/name}","comments_url":"https://api.github.com/repos/opensim-org/opensim-core/issues/1225/comments","events_url":"https://api.github.com/repos/opensim-org/opensim-core/issues/1225/events","html_url":"https://github.com/opensim-org/opensim-core/issues/1225","id":174392049,"number":1225,"title":"Matlab crashing during multiple simulation due to Reporters/TimeSeriesTable","user":{"login":"jimmyDunne","id":5296507,"avatar_url":"https://avatars.githubusercontent.com/u/5296507?v=3","gravatar_id":"","url":"https://api.github.com/users/jimmyDunne","html_url":"https://github.com/jimmyDunne","followers_url":"https://api.github.com/users/jimmyDunne/followers","following_url":"https://api.github.com/users/jimmyDunne/following{/other_user}","gists_url":"https://api.github.com/users/jimmyDunne/gists{/gist_id}","starred_url":"https://api.github.com/users/jimmyDunne/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jimmyDunne/subscriptions","organizations_url":"https://api.github.com/users/jimmyDunne/orgs","repos_url":"https://api.github.com/users/jimmyDunne/repos","events_url":"https://api.github.com/users/jimmyDunne/events{/privacy}","received_events_url":"https://api.github.com/users/jimmyDunne/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2016-08-31T22:13:52Z","updated_at":"2016-09-17T09:25:11Z","closed_at":null,"body":"\r\n[double_pendulum_markers.osim.zip](https://github.com/opensim-org/opensim-core/files/448366/double_pendulum_markers.osim.zip)\r\n\r\nRunning multiple forward simulations in a loop (with reporters) continually crashes Matlab. \r\n\r\nIf I pass the function a model object, it will not run a second time (fwd_simulation function at bottom of post). \r\n\r\n```\r\nimport org.opensim.modeling.*\r\n\r\nmodel = Model('double_pendulum_markers.osim');\r\ntime_interval = 0.01;\r\ndefault_coordinates = [0.5 0.3];\r\n\r\nfor i = 1 : 100\r\n    [coordinatetable, markertable] = fwd_simulation(model, time_interval, default_coordinates, false)\r\nend\r\n```\r\n On the second iteration I get this error;\r\n\r\n```\r\nError using fwd_simulation (line 57)\r\nJava exception occurred:\r\njava.lang.RuntimeException: Timestamp at row 10001 with value 0.000000 is less-than/equal to\r\ntimestamp at row 10000 with value 10.000000\r\n\tIn file\r\n        /Users/jimmy/repository/opensim-master/opensim-core/OpenSim/Common/TimeSeriesTable.h:194\r\n\tIn function 'validateRow'\r\n\tat org.opensim.modeling.opensimModelSimulationJNI.Manager_integrate__SWIG_1(Native Method)\r\n\tat org.opensim.modeling.Manager.integrate(Manager.java:183)\r\n```\r\n\r\nI am interpreting this as there is a pesky TimesSeriesTable hanging around somewhere, even though everything should be getting wiped at the end of the function call. \r\n\r\nI managed to get it running more than once by passing the string name for the model and creating the Model object on the side of the function\r\n\r\n```\r\nimport org.opensim.modeling.*\r\n\r\ntime_interval = 0.01;\r\ndefault_coordinates = [0.5 0.3];\r\n\r\nfor i = 1 : 100\r\n    [coordinatetable, markertable] = fwd_simulation('double_pendulum_markers.osim', time_interval, default_coordinates, false)\r\nend\r\n```\r\n\r\nThis allows me to run the function more than once (great!), but it will crash Matlab after 10 iterations without warning or sufficient error message. \r\n\r\nIf I do not create any reporters in the function, it will run continually (tested up to 100 iterations)\r\n\r\nSomething funky is going on with Reporters and tables, so if anyone can give it a test that would be super. \r\n\r\n\r\n\r\n\r\n```\r\nfunction [coordinatetable, markertable] = fwd_simulation(modelname, time_interval, default_coordinates, plotMarkers)\r\n\r\nimport org.opensim.modeling.*\r\n\r\n%% add a table reporter for the coordinates\r\ncoordinateReporter = TableReporter();\r\ncoordinateReporter.set_report_time_interval(0.001)\r\ncoordinateReporter.updInput('inputs').connect(model.getCoordinateSet.get(0).getOutput('value'), 'q1' );\r\ncoordinateReporter.updInput('inputs').connect(model.getCoordinateSet.get(1).getOutput('value'), 'q2' );\r\nmodel.addComponent(coordinateReporter);\r\n% \r\n\r\n%% add a table reporter for the markers\r\nnMarkers = model.getMarkerSet.getSize;\r\nmarkerReporter = TableReporterVec3();\r\nmarkerReporter.set_report_time_interval(time_interval);\r\n\r\nfor iMarker = 0 : nMarkers - 1\r\nmarkerReporter.updInput('inputs').connect(model.getMarkerSet.get(iMarker).getOutput('location'), char(model.getMarkerSet.get(iMarker).getName) );\r\nend    \r\n\r\nmodel.addComponent(markerReporter);\r\n\r\n%%  Configure the model.\r\nfor iCoordinate = 0 : model.getCoordinateSet.getSize - 1\r\n        model.getCoordinateSet.get(iCoordinate).setDefaultValue(default_coordinates(iCoordinate+1))\r\nend\r\n\r\n% Simulate.\r\nstate = model.initSystem();\r\nmanager = Manager(model);\r\nmanager.setInitialTime(0); manager.setFinalTime(10.0);\r\nmanager.setWriteToStorage(0) \r\nmanager.integrate(state);\r\n\r\n%% get the coordinates\r\ncoordinatetable = coordinateReporter.getReport();\r\n\r\n%% get the markers\r\nmarkertable = markerReporter.getReport();\r\n\r\nclear model\r\nclear state\r\nclear manager\r\nclear markerReporter\r\nclear coordinateReporter\r\n\r\n```"},"comment":{"url":"https://api.github.com/repos/opensim-org/opensim-core/issues/comments/247759387","html_url":"https://github.com/opensim-org/opensim-core/issues/1225#issuecomment-247759387","issue_url":"https://api.github.com/repos/opensim-org/opensim-core/issues/1225","id":247759387,"user":{"login":"tkuchida","id":4203505,"avatar_url":"https://avatars.githubusercontent.com/u/4203505?v=3","gravatar_id":"","url":"https://api.github.com/users/tkuchida","html_url":"https://github.com/tkuchida","followers_url":"https://api.github.com/users/tkuchida/followers","following_url":"https://api.github.com/users/tkuchida/following{/other_user}","gists_url":"https://api.github.com/users/tkuchida/gists{/gist_id}","starred_url":"https://api.github.com/users/tkuchida/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tkuchida/subscriptions","organizations_url":"https://api.github.com/users/tkuchida/orgs","repos_url":"https://api.github.com/users/tkuchida/repos","events_url":"https://api.github.com/users/tkuchida/events{/privacy}","received_events_url":"https://api.github.com/users/tkuchida/received_events","type":"User","site_admin":false},"created_at":"2016-09-17T09:25:11Z","updated_at":"2016-09-17T09:25:11Z","body":"> That would mean that upon getting the report (TimeSeriesTable) the internal report would be cleared, correct?\r\n\r\nYes. In most scenarios, I would expect users to get the TimeSeriesTable exactly once, so the \"clear on read\" behavior would *just work* without the user needing to think about it. The user could be inconvenienced in two ways:\r\n\r\n1. Attempts to read the TimeSeriesTable twice – I think this scenario is unlikely to be problematic, as it seems like the user should be able to hold onto the Table and extract all necessary information without wanting to fetch it again. If the user attempts to read an empty Table, we could throw an exception like \"The Table is empty: either it has not been filled, or it has been read which causes an automatic clear\".\r\n\r\n2. Attempts to overwrite the TimeSeriesTable without reading/clearing – This scenario could occur if the user is, say, running a simulation in a loop and cares only about the Table after the last iteration. In this case, an exception should be thrown indicating that the user must clear or read-and-clear the Table before writing to it again.\r\n\r\n> If you do not get the report than is it expected that you want to continue to append during subsequent simulation?\r\n\r\nI think an exception should be thrown before writing a non-increasing time (e.g., restarting a simulation from t=0), but time-stepping or pausing and resuming the simulation where it left off should be permitted.\r\n\r\n> We should also clear if the System is rebuilt.\r\n\r\n:+1:\r\n\r\n> …and list potential remedies to: 1. get the report (which will clear), or 2. manually clear before re-running the simulation.\r\n\r\nThat sounds good. IIRC, hardware registers often don't have a separate `clear()` method (you need to perform a read-and-clear by reading into a trash variable). Having a separate `clear()` method violates the \"minimal API\" rule, but in this context I think it would be cleanest."}}
{"actor":{"display_login":"tkuchida"}}