Introducing IRMA installation logistics capabilities #25
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is focused on a framework for representing installation actions to start with. Located in Irma folder for now. Irma.py has the basic script for trying things out, and more importantly a draft Scenario class that manages actions and related info. Includes Rudy's graph theory representation and plotting function. Actions.py has the class that covers individual actions. Four YAML files give an outline/beginning of a framework to represent how various vessels/assets, capabilities, and actions can be interrelated and organized.
- Expanded the yamls, especially vessels.yaml
- - vessels.yaml now includes previous work from Rudy, including
one example adapted to the new (draft) structure.
- - TODO: finish updating vessels.yaml to follow the new structure.
- - Switching yamls over from lists (with a name entry) to dictionaries.
- Started assets.py, which takes vessel and port classes from Rudy
(with some refinements from Ryan) and begins a more combined approach
with an Assets base class. Work in progress.
- Started Task class in task.py to hold groups of actions. - Cleaned up Action class a bit. - Outlined more steps in Irma.py script.
- Updated actions.yaml (half way done) to use a nested roles->capabilities dictionary rather than requirements and capabilities lists. - Actions class now has assets and requirements dicts that correspond to roles/capabilities in the YAML. - Draft outlines of Action methods assignAsset and checkAsset
…apability capacity
…ain irma example: - The __main__ example in irma takes the keyname of the objects and assign it to the name of the action. - irma checks for duplicate action names and flag a warning in registerAction method, - day rates of various vessels obtained from ORBIT and other sources are provided in the vessels.yaml file, - Updating visualizeActions method to give equal axis and showcase action starters with a green colored node.
- task is given a list of actions that we can do duration and cost analysis on to clump certain actions together. - irma main file updated to generate a task given actions.
…signAsset` which is called by `assignAssets` for each `{role : asset}` pair. Sets up structure for checking different asset combinations for action. Removes requirements from `actions.yaml`.
…signed in`action.py`
…alculations for capability requirements and action cost and duration.
…ity: - Fixed/finished unifyUnits function -- it now (seems to) work... - Uncommented the call to unifyUnits so it's now applied to vessel yamls. - action.py: Commented out a syntax issue and made it so that assignObjects method doesn't also figure out the required capacities (so that code will run, and that could be a separate step anyway). - Moved the test call to evaluateAssets in Irma.py to later in the script after all the actions are set up. More organized order, and lets the existing code still run.
- Commented out placeholder code that has invalid syntax - Added placeholder duration for install_anchor task to calculate install costs - Removed unnecessary clearing of assets dictionary when excpetion is raised
- get_row function structure added to task class - get_row returns a len(assets)x2 array of zeros for runability of code. This will need to be changed with a real calcualtion of costs and durations - Irma constructs a task asset matrix by adding up these rows - The task asset matrix built by irma is rows = tasks, columns = assets
- Builds a scheduler class - Example code in main block allows scheduler to be run standalone with example of tasks and assets - Eventually main code block will need to be replaced by irma - Code runs, does not produce optimal solution. Constraints need to be finished and checked they are working properly.
- Added Scenario methods to add and register Tasks. - Added a action_sequence input in Task that provides the ordering of actions within the task, including parallel/serial bits. - Started an example "strategy implementer" function in irma that sets up one Task for anchor installation to start with. - Added ti/tf placeholders in Action and Task for future timing. - All work in progress...
- Adds constraint 10 to scheduler, enforcing tasks cannot be assigned to periods where they don't have enough time to be completed - Adds ideas for constraints 2 and 9, but further work is needed - Adds a scheduluerREADME with theory information. This can be generated automatically from the docstrings in constraint explainations. - Adds a more complex example case to the main block of file for testing
- Adds printing of the constraint matrix for each constraint if wordy = 2 - Additional printing possible with wordy = 3 - Wordy = 0 disables all printing - Fixes typo in docs for constriant 2
… the sequence graph: - sequence graph simplified (without labels) and with a title that describes the actions that are done by each checkpoint (and/or end) node. - sequence graph calculates the total duration based on the thickest edge (largest duration) between the checkpoint nodes. - assigns the duration back to task self while also populating actions_ti relative starting time of each action in the self.
…n the sequence graph:
- sequence graph simplified (without labels) and with a title that describes the actions that are done by each checkpoint (and/or end) node.
- sequence graph calculates the total duration based on the thickest edge (largest duration) between the checkpoint nodes.
- assigns the duration back to task self while also populating actions_ti relative starting time of each action in the self. + removed a zero
- changes from single 3D decision tensor to 4 2D decision variables - updates constraints accordingly and adds new constraints - updates and polishes documentation to reflect complete, inprogress, and todo constraints
- Finalizing updates to all the new constraints with a write up in the scheduler README, in order - Deleted all of Ryan's old constraints that I figured didn't apply any more (either didn't make sense, or were redundant) - Kept the numbering scheme the same for now - Need to address a problem in the future (probably) regarding the duration of tasks that have the same asset
… ability in task, assign asset for task 1 instead of just evaluating them: - mobizilize calcDuration is hardcoded based on the vessel used. - extract sequence yaml file from task.py so the user can edit things like durations. - update from the sequence yaml in task.py to enable user-defined durations. - changing site_distance_m to route_length_m to avoid confusion. - calwave main task1 example assigns assets to actions instead of just evaluating them.
- Eliminated the lower bound constraint for Constraint 3, which allowed multiple assets to be assigned to the same task - - It is now an equality constraint, where each asset (column in the task-asset matrix) corresponds to an 'Asset Group', which is a combination of assets that is used to perform each task - - This prevents multiple asset groups from being used by the same task, but this means that many asset groups need to be defined to cover all asset combination possibilities - - - Another script is in the works to generate the task-asset matrix based on asset capabilities and task requirements, but for now, we can just look at the example at the bottom of the scheduler.py script - We initialize new asset groups, which generate dictionaries in '_initialize_asset_groups', which are now used by Constraint 4 to ensure that the same asset used in different asset groups is not used by multiple tasks in the same time period - A small print help - Initial commit for the scheduler_tutorial.ipynb to detail how the scheduler works
- commented out the Xap variable lines - added a bunch of self variables to save constraint rows - constraint 2 is now in an if statement in case there are not any dependencies specified - commenting out constraint 12 - using the minimum weather maximum of the asset group to set the weather constraints - some updates to the schedulerREADME from new task-asset group matrix defining - full working scheduler_tutorial that is all up to speed and produces the right outputs
moving to irma folder
- Initial script to hopefully store any kind of test script that can run through the scheduler through its development - This may turn into a test script. It may turn into multiple example files...not sure yet - This is now the second working example of what's currently included (the first is what's at the bottom of scheduler.py)
- A new 'offsets' dictionary can be included as input to the scheduler, with a key corresponding to a dependency type - The concept is relatively simple and the implementation is not that bad - - The dependency constraint just adds the period value of an offset corresponding to a dependency type and essentially just updates the for loop of the number of start times to consider while making constraints - - - for example, if there was an offset of 1 period for one task to start after another task finished, then the constraints would make more rows to correspond to higher start time constraints - - does this for multiple dependency types and updates the constraints fittingly - also updated some printing out of things - updated examples and the jupyter notebook tutorial to include dependency offsets - however, this doesn't ensure exact offsets - that might come in the next commit
- Realized that the previous commit didn't explicitly set the offset of one task to be exactly the specified amount after the task it's dependent on - This required splitting up the inputs into 'minimum' and 'exact' to allow for each scenario - - I'm not sure off-hand if we'll need each scenario, but I guess it's good to have just in case - Large change to the creation of Constraint 2, which mainly just split the process up into whether it's 'minimum' or 'exact' and used some nifty math to ensure that will be the case - Also added a new _parse_offset function to differentiate between different offset types and allow for different input formats (which are listed in the documentation of __init__) - Things are tested in scheduler_example and in the scheduler_tutorial, relatively - - I have this gut feeling that later tests/examples may encounter some small issues, but for the most part, the implementation should be good
…ffset constraints - explained differences between 'minimum' and 'exact' in how the constraints work
- updated all of Ryan's old 'wordy' sections to print more clearly what the constraints are - the task_asset_generator script is not meant for a permanent solution; it's meant to provide some kind of example of what we will need to do to generate task-asset matrix information based on certain task and asset inputs TaskAssetGroupGenerator - A new class to help organize task and asset input info in creating the proper inputs to the scheduler WORKFLOW 0) Start with a list of tasks and assets in a certain format - The user can input a certain 'strategy' (like a LineDesign configuration) to specify what tasks are needed - Meaning, the parameterization of tasks should be defined by the user (or at least the strategy of how the tasks should be parameterized) 1) 'Validate' the task and asset definitions - makes sure the input format is how it should be and all entries are standardized 2) Generate feasible asset groups - make 'groups' of each individual asset (like normal), and then build combinations of each asset (up to a maximum group size) and evaluate whether that group is operationally feasible - operationally feasible is based off of weather, capabilities, overlapping capabilities, total cost, etc. - if feasible, then we can calculate their group properties (to match the dictionary format of asset groups) - - sum costs, minimum weather, etc. - (!! we can change these later !!) 3) Match tasks to asset groups - determine if asset group has the capabilities to perform each task (and works with its weather rating) - if they're compatible, calculate the cost and duration (!! can also be updated later !!) - creates a list of feasible groups per task that get stored in 'task_asset_matches' 4) Build task-asset matrix - builds the matrix off of 'task_asset_matches' with -1's as defaults - the 'sparseness' is a pre-processing step in evaluating the feasibility of each task-asset combo
- StageActions: This method stages the action_sequence for a proper execution order (in the task initialization, it is called if an action sequence is not provided). Currently, it takes an argument 'from_deps' to compute the sequence based on the inter-action dependencies but the idea is to enable other strategies later to be built to create the action_sequence in the Task for more autonomy. - calcDuration - This organizes the actions to be done by this task into the proper order based on the action_sequence. This is used to fill out the self.actions_ti (the initial time of individual actions within the task), self.ti, and self.tf. Right now, when we're initializing the task, we assume a ti of zero. - calcCost - This calculate the total cost of the task based on the costs of individual actions (a simple roll-up). This updates self.cost. - Both calcDuration and calcCost assumes that the individual action.duration and action.cost have already been computed (using calcCostandDuration in the action class but I'm also thinking of dividing this method into two different methods - one for cost and one for duration to match with Task.py and also task-assets matrix in the scheduler. - updateTaskTime: This method updates the starting and finishing time of the whole task and the starting time of individual actions based on a new start time passed to Task (could be helpful later during task scheduling using the sceduler.
- fixing other instances where Tasks are generated in irma.py with names being mentioned as the first argument, - sequence Graph updates duration and actions_ti - allowing actions fed into tasks to be either list or dictionary for flexibility
- Made action_sequence input support both dict and string options. - Moved the dependency-based sequencing code into .init. - Added a 'series' option as default, putting every action in order. - Removed some of my now-redundant code in Irma implementStrategy_staged.
Updated the following files with the calwave_ additions: - action.py - actions.yaml - capabilities.yaml
…and capabilitiy mapping - Examples won't work with this commit: - roles are replaced with requirements dictionary in the init of action.py. The keys are the requirements that will be mapped to asset capabilities and values are booleans of True and False (depending on the objects and material constraints described in requirements.yaml. - requirements.yaml dictionary now should be inputted when creating the action <not very clean and we should think of a different way of doing that> <we don't need all Requirements, just the ones listed in the actionType>. - roles still exist in checkAsset, evaluateAsset, assignAsset, etc., this is work in progress. - removed stageAction from Task.py. - clear assets after assigning them in action and task - update task finish time in task.calcDuration function - updated actions.yaml, capabilities.yaml, and requirements.yaml.
…main example in action.py: - removing previous format of needing a role for assets to perform in main methods of the action class. Mainly in - - checkAsset: checks if requirements are met by the asset capabilities and if not provides a full description of what cap was not met. - - evaluateAsset: temporarily assigns (if assignable) an asset to emphasize that all requirements are met to calculate duration and cost. - - assignAssets and assignAsset: not only do we check if the asset is assignable, but we also check if assigning that asset makes any sense by comparing what this asset can provide versus what requirements have not been met yet (e.g. by previous assets). For example, it makes no sense to assign two barges that each fulfil all requirements. But maybe later on, we could assign 'metrics' to req-cap and then it might make sense to assign two assets that fulfil the same requirements (for example two barges, each holding half the required amount of anchors). - - calcDurationAndCost: there's a lot of work that needs to be done on this function still to remove all roles format. I've only fixed the install_anchor example (with a short-term fix) to get an example to run. - There is a 'main' example inside Action.py to test these different methods. Action now is consistent with itself (except most of the calcDurationAndCost method). - I'm not using updating Requirement function for now. It's left for future work. - local fixes to irma.py but main example still won't work.
Some edits to add/restore account for capability specs (aka metrics) in the setting of requirements and checking of asset suitability. irma.py - Scenario.addAction now prepares a nested dict for all the possible requirement -> capability -> specs, initialized to zeros. Action class: - Action.requirements is now a nested dictionary that includes the capabilities and specs for each requirement. - Action.updateRequirements now fills in required specification values based on the objects involved. Just a start so far - lots to be added. - New method checkAssets, checks whether a combination of one or more assets can meet all required capability specs. (Can probably replace checkAsset.) - Commented out materialList and allReq - maybe not needed anymore. - Edited script at bottom to try out the updates capabilities.yaml: removed name field, to make names keys. requirements.yaml: made a couple small edits.
- fixing anchor type from suction_pile to suction in the example ontology file we use in the main script of action.py (this is based on the new anchor terminology). - evaluateAssets + assignAssets functionality in Action.py still won't work (WiP) as they are calling calcDurationAndCost function which we need to work on. - work in action.py includes: - - checkAssets function corrected to set requirement to meet if one or more capabilities are available (and are capable to provide the necessary specs demanded by the project). - - I've divided anchor_handling into anchor_overboarding, anchor_lowering, and anchor_orient to show an example of how a capability within each of these requirements are needed be fulfilled by the combined capabilities of all assets. - - These calculations in updateRequirements based on the install_anchor action requirements are set as an example but the numbers could change (example of doing such calculations). - Other changes include: - - changing bollard pull requirement to towing. - - stern_roller does not have diameter_m but just width_m spec.
- Added (mostly) deck space requirements to Action.updateRequirements() for chain, rope, and anchors based on external data - - Still some things to go over, like the orientation of a suction pile, and how standardized rope reel deck space amounts are (and whether they depend on the asset) - Also some updates to irma.py to work with findTaskDependencies, which works, but can be extracted to inputs to the scheduler
Too many changes to detail, but key points are: Action class: - new Action.dependsOn method for easy dependency check. - expanded/adjusted Action.updateRequirements with more reqs and more consistent calcs. - expanded/adjusted Action.calcDurationAndCost with more actions and a more consistent approach to summing costs and durations. - Added Action.durations and .costs (with an s) to store itemized values. Requirements: - Added "direction" to storage-related reqs. +1 means loading, -1 unloading. - Added "selected_capacity" field to say which capacity will be used. - Added "assigned_asset" field to say which asset will be used to meet that capacity. Task class: - Task.act_sequence is the actions in sequence form (a list in order) - Added a bunch of logic in Task.init to figure out the overall requirements of the task considering all its actions. Currently only works for serial action sequences (no parallel actions). - Adjusted updateStartTime and renamed to setStartTime. - Added Task.chart, which is a slightly streamlined version of calwave_chart, as a Task method. - Added helper functions for processing dependencies, checking asset suitability, etc. imra.py example script: - Some temporary additions for computing general properties of Project class objects for use in IRMA. To be moved eventually. - Added some code to demo the asset assignment and make a Felipe-style plot. Edits to some YAMLs to get thigs working and deal with a couple outlier entries.
- Enabled the unit converter when loading YAMLs in Irma.py.
- capabilities.yaml:
- - changed spec names to use fundamental SI units.
- - commented out some weight/dimension specs that may not be necessary.
- - added "type" values to denote how each spec should be treated
(this is for upcoming changes not yet implemented)
- Changed associated keys/calculations in action.py to mainly
use SI units.
- added a printStruct function to nicely display nested lists/dicts.
Run code - Set up code to run the scheduler after everything else in Irma.py was run: tasks, assets, asset_groups (which can be automated later), the task-asset-group matrix, and then dependencies and time offsets - - The dependency offset times are the output of sc.figureOutTaskRelationships - - The task-asset matrix cost and duration values come from task.calcDuration and calcCost and checks each asset group validity Time intervals - Implemented a duration interval in Task.calcDuration() to set the duration to the nearest interval - Task earliest start and finish times are calculated using dependencies, but also to get the last (finish) time to set the number of periods (as a function of the time interval too) - findTaskDependencies now use the time interval too to calculate dt_min - - It also updates to the minimum of time_1_to_2 (still ignoring the other way for now), but ensures that it returns -2.3 over -4.5, since the absolute value is the value we care about here scheduler - updated the wordy parameter to a self parameter - Made a new Gantt chart-style print output (for now)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds the in-progress IRMA modeling capabilities in an "irma" subfolder. These capabilities are currently on their own and not used by anything else in the repository. They are still a work in progress, but that work can proceed within the more up-to-date and merged dev branch going forward.