GithubHelp home page GithubHelp logo

konstantinosrekoumis / csr Goto Github PK

View Code? Open in Web Editor NEW
2.0 1.0 2.0 319 KB

A primitive calculator that calculates a ship midship plates and PSMs based on IACS CSR

Python 95.73% TeX 3.60% Shell 0.67%
shipbuilding rule-based-design

csr's Introduction

Constructional Strength Calculations

This was part of a ship design assignment, by SNAME @ NTUA.

Primary goal

This code is developed to aid the design of the principal strength members of a ship's Midship. For the time being is developed for Bulk Carriers, under Common Structural Rules.

Contributing

Installation

Python3.12 or later REQUIRED!

git clone [email protected]:KonstantinosRekoumis/CSR.git && cd CSR
python3 -m venv venv
source ./venv/bin/activate
pip install -r requirements.txt

Build

Configure the hooks:

# this will automatically run some predetermined steps before each stage
git config core.hooksPath ./hooks

If you want to read the generated junit reports locally, install xunit-viewer && chromium.

sudo npm install xunit-viewer -g
sudo dnf install -y --best --allowerasing chromium

Running

CLI

# activate the virtual environment mentioned above
source ./venv/bin/activate
# run
./cli.py "path/to/envelope.json"

GUI

# activate the virtual environment mentioned above
source ./venv/bin/activate
# run
./gui.py

Design Comments on the Ordinary Section

  • The Weather Deck is thicker than calculated to get a boost in Z,deck (also we done no calculations for the hatch coamings)
  • The Weather Deck stiffeners are essentially impostor bulbous stiffeners
  • The Inner Bottom and Bottom Shell plates are roughly the same size for construction homogeneity
  • The wing tank makes sense to have multiple plates like in the mother ship though design is kept simple for the time being.
  • The plates where given dimensions based on the mother ship without following them to heart
  • The plates may be thicker than the calculations imply but this is done to ensure we have adequate area moments

Goals

  • Finish CSR for thesis
  • Add functions to export calculation data to a reportable form (copium) (base is probably done, need to actually use and grab function values)
  • PSM spacing per plate to account for Bulk Carriers (reasonable)
  • Add info about the null corrosion check done for girders
  • Fix Z calculation for stiffener
  • Add t_net calculated
  • Girder LaTeX fix for Corrosion thickness
  • Add info about the null corrosion check done for girders
  • Fix the input file for the Tmin, Lsc and Tsc
  • Account for symmetry
  • Add I calculation for symmetrical sections
  • State the axis convention(done the graphical important thing)
  • Include the girders in the calculations
  • Include null plates to define volume without joining in the strength calculations
  • Create I and Z checks
  • Calculate I_{y-n50} and I_{z-n50} (with corrosion addition)
  • FIX FOR STATIC LOADS AT PLATING AND STIFFENER SCANTLING (not sloshing bs)
  • Check special plating cases -> side shell (ez) -> Bilge plates(medium) Bilge plate needs to have as paddings the neighboring plates' inverse paddings
  • Program T beams for stiffeners
  • IMPLEMENT BUCKLING STRENGTH CHECK -> Implement shear beam reduction (check for total Moment of Inertia) Part 1 Chapter 8 Section 2
  • Finalize the Section Modelling
  • Create exception for fender contact zone
  • Modify the corrosion addition function to account for 0 state entry ( all thicknesses are less than corrosion addition)
  • ESSAY -> Change the table figures, iamges, check for mistakes, add beff in Inertia Calculations
  • Close the LaTeX export (check the savefig func)
  • Not lose sanity
  • physics module HSM ans BSP need Lwl not LBP on weather deck calculations (actually they needed Lsc)
  • Fix colorbar, added multiple subplots
  • kr and GM calculation is different for WB, add to __init__() (actually use it)

Future Extensions

  • Augment the physics external_loadC method to account for more cases (only fully supports HSM and BSP) ( PhysicsData class fixed the is sue)
  • Augment rules to automatically check if a plate's material is of correct class
  • Play with colormaps in contour plots
  • Improve documentation

LICENSE

MIT License

Copyright (c) 2022 Konstantinos Rekoumis

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

csr's People

Contributors

gerelef avatar konstantinosrekoumis avatar

Stargazers

 avatar  avatar

Watchers

 avatar

csr's Issues

Replace Logger with loguru

Lay the groundwork for #22 by replacing Logger with loguru.
Logger was introduced as an intermediary step between pure if debug print statements, and a safe & feature-complete Logger implementation.
Now, with #22 in mind, it's time to move away from it, and introduce a multiprocess-safe logger.
Some features (that already exist in our own implementation) are:

And these extra, useful features:

With verbose exceptions, we'll be able to eliminate all Logger.error(...)s with a simple assert, letting the verbose exception show the values that crashed the system runtime.

This supersedes and closes #25

Implement the Standalone behavior for the LaTeX output functions

During the latest refactoring of the codebase the LateX export functions lost their full functionality.
Standalone behavior is a feature that is currently missing.

Also might as well implement more features in the Standalone Report like ToC, ToF, etc.

Running the commands to build the report may be a useful addition as well.

Implement way to get absolute path pointing to a resource

This will increase compatibility with other interfaces which do not expect a file's contents but rather the absolute path towards it.
The current implementation only supports getting a resource with a context manager (with ... as r).

#23 related

Restructure existing logical components

The current implementation is leaking all over the place; everything but the kitchen sink is checking any Block's instance members, for numerous reasons. This is a significant code smell, and a clear violation, of encapsulation. The consequence is that the coupling between the Block class and the entire project is very, very tight, meaning we cannot make any sane changes without the entire project going kaput.
To add to the significant issue mentioned above, there's another problem that consistently appears throughout the project, which is that there are a ton of duplicate checks (if an imported material is in the materials list, for example) scattered throughout the project. This makes the situation even harder, since we have to keep checks that might be either redundant or integral to the regular operation of the program.
The first step to refactoring, not only the Block class, but all other components, should start at it's root:

  • Centralize & employ all checks that are integral to the program in our input fn/method/class/whatever.
  • everything else!

This issue is a generic one at that; it's here to reference when documenting logical structural changes i.e. the refactoring of the Block class.

Decouple LaTeX code from Python

Issue

Currently, tens of LaTeX loc are embedded in python; they are not only hard to edit, but they obsfuscate the code, detracting from focusing on what's important while fixing bugs and/or refactoring. Moreover, the current approach is less extendable, and more prone to bugs due to being hard to statically analyse with external tools.

Proposal

Move appropriate latex code segments from being embedded in python code, to a dedicated resource directory for application files.

Rules and Pressures Calculation Speed Up

Current problem:

  • Pressure distribution for each Loading Condition is done in series for each EDW in the condition and then for each plate.
    Proposal : Use multiprocess library to fractalize the computations to multiple processes and assess the possible performance gains
  • Checking the rule thickness criteria in parallel for each plate

Open to implementations ....

Add generated __str__ implementation for all widely-used classes

Issue

Numerous classes currently have numerous Debug methods that are manually written & updated, whose only function is to print some instance members to stdout. This is unsustainable and error prone; a standard solution is required across the entire project.

Proposal

Use auto_str from my personal dotfiles to automatically implement this behaviour; this requires no external modules in requirements, and should work well for anything we throw at it, as well as being well tested across different projects.
https://github.com/gerelef/dotfiles/blob/7e21e2e35ccb0dd3c47cfbb21db80f5d5e0f3f2c/scripts/utils/modules/update_utils.py#L45-L75

[Bug] Potential obfuscation of program-terminating error

There's a code segment in plate.py (copied for convenience):

except KeyError:
    print("The axis dictionary is not properly structured")
    return 0
except TypeError:
    print(
        "The axis dictionary has no proper values.\n",
        "axis :",
        axis["axis"],
        type(axis["axis"]),
        "\noffset :",
        axis["offset"],
        type(axis["offset"]),
    )
    return 0

Shouldn't the program die if the axis dictionary values are improper(ly structured)?

Replace old-school style debug prints/error functions with dedicated static class

Issue

if debug:
    print(st_plate)

Currently, there are many code segments which are unnecessary, as shown above; others involve c_error etc... which are an old-school (and still inefficient) way of doing debug-style prints/error messages

Proposal

Eliminate all debug keywords, they will be obsolete & replace with dedicated static class that accepts CSR_LOG_LEVEL style env variables, with 3 levels in the code; info, debug, warning error.

Refactoring the plate class

As of now, the plate class is implemented to account for only linear geometries with the only non-linear part being the bilge plate. The above design even though makes sense for simplicity purposes can handicap the program's ability to cope with more complex geometries (ie. Maybe the "hopper plate" can be a Quarter Circle plate).
Also, the pressure grid over each plate is calculated in the block class using an implicit algorithm that depends on the plate's positioning to calculate everything appropriately. As the new PressureContainer family of classes are to be implemented the above overly complex and hard-to-maintain algorithm will be axed in favor of calculating the pressure grid off each plate in the plate and then passing it whenever it is needed.
So, what needs to be done:

  • Create more plate-inherited classes that can describe more complex geometries
  • Fix the IO so the Saver / Loader can deal with the new classes. (maybe implement on the classes instead of the IO modules)
  • Offload the pressure grid calculation to the plate class
  • Implement the PressureContainer Class

Sane management of local resources

We need a sane way to manage project resources, such as template files and/or (possible) translation files, etc.
The industry standard is to use a "Resources" directory, which is accessible from wherever needed in the application, without battling with paths.

This answer describes what seems to be the standard for Python. More research is needed, but this seems like a sane solution.

#4 related

Block Class enhancement

Currently the block plate class is not properly structured and tries to cope with multiple issues at the same time.
As @gerelef has suggested, maybe a better solution is to create child classes that inherit from the base class.
However, this is not yet implemented as the Block class is responsible to calculate the Kc factor for the Dry Cargo block.
Though, after a useful comment from QA I think is sane to move this calculation inside the dynamic_dry_cargo_pressure function, where the Kc is actually only used.
So, the Block class will truly become space type agnostic and child classes can be created to specialize each block. The only problem that may arise with that implementation is that a Cargo Hold in a Bulk Carrier can be designed as both a Liquid Cargo, and Dry Cargo space.

The only thing missing for the above changes to be implemented is that the Kc function respects the local properties of the coordinates (aka from which plate are derived) as the Kc factor is zero for Bilge, Wing, WeatherDeck plates.

Deepen project structure hierarchy to reduce number of classes in specific grossly overloaded "god files"

Issue

Some files currently suffer from being "god files" if you will, since they are thousands of lines long for no good reason; they just a lot of different classes in the same file. This makes it harder to collaborate on different parts of the project with multiple, since everything is coupled together on the same file, making the experience of merge requests significantly worse.

Proposal

Split every class to it's own file & create directories according to responsibility, rather than inserting everything in the same file.
Files with very similar functionality should be on the same directory depth.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.