Architecture doc #612
Merged
Architecture doc #612
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
added 2 commits
February 9, 2024 09:01
koubaa
requested review from
PipKat,
dipinknair,
klmcadams,
samigithub2022 and
sbradrick
github-actions
bot
added
the
documentation
sbradrick
reviewed
Feb 20, 2024
Collaborator
|
Hello:
Because this is a semi large chunk of doc, I want to use email to iterate.
=====
My revisions...
To improve efficiency, Mechanical currently enables you to use Python API capabilities to automate repetitive processes.
You can also use APIs to customize your workflows by creating customized options, objects, as well as to incorporate third-party solvers in order to enhance pre- and post-processing capabilities.
However, APIs do not use a version of the *Command pattern* (see below).
I’m getting lost here. Something does seem right.
Because the API serves the needs of both *automation* and *customization*...
Instead, the API provides the data model directly as the API?
There doesn't seem to be a logical bridge between the above statements... They don't tie together.
Instead, the API (PyMechanical?) provides the data model directly as the API. Mechanical's data model uses Object Oriented Programming, or OOP. With OOP, _Objects_ contain data and operations on that data. The Mechanical API interacts with the _Objects_, giving access to their _Properties_ and _Methods_. The API also provides the _Enums_ that are used by the _Properties_ and _Methods_.
=====
My revisions...
…________________________________
From: Mohamed Koubaa ***@***.***>
Sent: Tuesday, February 20, 2024 12:12 PM
To: ansys/pymechanical ***@***.***>
Cc: Sean Bradrick ***@***.***>; Review requested ***@***.***>
Subject: [ansys/pymechanical] Architecture doc (PR #612)
[External Sender]
________________________________
You can view, comment on, or merge this pull request online at:
#612
Commit Summary
* 455490a<455490a> start
* bb77898<bb77898> finish
File Changes
(2 files<https://github.com/ansys/pymechanical/pull/612/files>)
* A doc/source/architecture.rst<https://github.com/ansys/pymechanical/pull/612/files#diff-0551ce601f332f439ac48dc5a6a834dd504733aca1fc0972e6dba6b8f498f3c6> (188)
* M doc/source/index.rst<https://github.com/ansys/pymechanical/pull/612/files#diff-1e3ed06e90fe3bf5ecf311ac1bd22215144cfc8c0924f5e05e3394573d630ceb> (6)
Patch Links:
* https://github.com/ansys/pymechanical/pull/612.patch
* https://github.com/ansys/pymechanical/pull/612.diff
—
Reply to this email directly, view it on GitHub<#612>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BBIIIZTBALPC5T6RKEUMSR3YUTKOJAVCNFSM6AAAAABDRRKCISVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE2DIOBXGM2TAOA>.
You are receiving this because your review was requested.Message ID: ***@***.***>
|
sbradrick
reviewed
Feb 20, 2024
sbradrick
reviewed
Feb 20, 2024
dipinknair
reviewed
Feb 21, 2024
Co-authored-by: Dipin <26918585+dipinknair@users.noreply.github.com>
Co-authored-by: Dipin <26918585+dipinknair@users.noreply.github.com>
sbradrick
reviewed
Feb 21, 2024
sbradrick
reviewed
Feb 21, 2024
sbradrick
reviewed
Feb 21, 2024
sbradrick
reviewed
Feb 21, 2024
sbradrick
reviewed
Feb 21, 2024
sbradrick
reviewed
Feb 21, 2024
sbradrick
reviewed
Feb 21, 2024
sbradrick
reviewed
Feb 21, 2024
PipKat
reviewed
Feb 21, 2024
PipKat
reviewed
Feb 21, 2024
PipKat
reviewed
Feb 21, 2024
PipKat
reviewed
Feb 21, 2024
PipKat
reviewed
Feb 21, 2024
PipKat
reviewed
Feb 21, 2024
PipKat
reviewed
Feb 21, 2024
PipKat
reviewed
Feb 21, 2024
PipKat
reviewed
Feb 21, 2024
PipKat
reviewed
Feb 21, 2024
PipKat
approved these changes
Feb 21, 2024
added 2 commits
February 22, 2024 11:45
Collaborator
Author
|
@PipKat @sbradrick I've incorporated some of the feedback and pushed again. The "Distributed Systems" section is probably the least clear in my opinion, I will give it some more attention/rework tomorrow |
klmcadams
reviewed
Feb 22, 2024
Collaborator
klmcadams
left a comment
klmcadams
left a comment
There was a problem hiding this comment.
This was really good! It made sense to me. I just had a question about what categories you were referring to in the "Message Passing APIs" section. The footnotes & links were a nice touch for additional explanations
sbradrick
reviewed
Feb 26, 2024
| Command pattern | ||
| --------------- | ||
|
|
||
| Many interactive apps use the command pattern. It turns anything that the user |
Collaborator
There was a problem hiding this comment.
...anything that you do within the app into a command object...
sbradrick
reviewed
Feb 26, 2024
| Mechanical app in-memory inside of a Python program. There is no additional | ||
| running process associated with it. Mechanical's data model is directly | ||
| available within Python, which means that the fully CRUD data model of the | ||
| mechanical API can be used. |
sbradrick
reviewed
Feb 26, 2024
| not meant be exhaustive and rigorous, but it instead introduces just the topics | ||
| necessary as simply as possible to help you understand the choices made by the | ||
| designers of PyMechanical. | ||
|
|
Collaborator
There was a problem hiding this comment.
This section contains a very basic explanation of distributed systems. It is not meant to be an exhaustive explanation, but rather an introduction to only the topics necessary to help you understand the choices made by the designers of PyMechanical.
sbradrick
reviewed
Feb 26, 2024
| is said to have done an RPC. Unlike a normal procedure call, it can be | ||
| unreliable and orders of magnitude slower. There also needs to be a handshake | ||
| so that both sides understand how to interpret the bytes that move on the wire | ||
| between computers [#f6]_. This handshake can be negotiated byte-per-byte, but |
Collaborator
There was a problem hiding this comment.
bytes that move between computers
sbradrick
reviewed
Feb 26, 2024
| that have been tried and tested. | ||
|
|
||
| While standards are useful, it is not practical for every developer to craft | ||
| packets to send over the wire by hand. Around the most popular conventions of |
sbradrick
reviewed
Feb 26, 2024
| should be written. Some offer low-level method invocation facilities, like gRPC | ||
| and zeroMQ. Others take a view on how RPCs should be done. Two such views are | ||
| *Representational State Transfer* (REST) and *Remote Method Invocation* (RMI). | ||
|
|
Collaborator
There was a problem hiding this comment.
However, libraries and tooling can be opinionated (? Have requirements about?) in how RPCs can and should be written. Some offer low-level method invocation facilities, like gRPC and zeroMQ. Others take a view on how RPCs should be done (such as?). Two such views are Representational State Transfer (REST) and Remote Method Invocation (RMI).
sbradrick
reviewed
Feb 26, 2024
| ------------------------ | ||
|
|
||
| In the nineties, *Object Oriented Programming* (OOP) exploded in popularity. | ||
| Among other things, OOP allows programmers to add abstractions on top of data |
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.
I wrote this page of the documentation to clearly explain why there is both a remote and non-remote PyMechanical interface, and why the remote interface looks like it does.