OpenSeesPy visualization packages about openseespy HOT 10 CLOSED

Since everyone agrees, we will remove the visualization packages from OpenSeesPy and OpenSeesPyDocs, and provides links to the separated packages and docs in the next release, which will likely happen after Oct. 15th.

I will create a new page in the OpenSeesPy documentation about the ecosystem of OpenSeesPy. The links will go there. Feel free to submit PRs to add your links there.

Please let us know if you have any other questions. Thanks a lot for contributing to OpenSeesPy community.

from openseespy.

Hi @silviamazzoni , no, very happy in python! Just a loose observation on trends in software really.

from openseespy.

@Heanmogo You should start a new issue since it is unrelated to the topic of this discussion.

This is because MVLEM_3D internally re-orients its nodes. The actual node sequence in its formulation is not the same as what a user provides. It is strange but that is how it is. None of the codes have an error. The plotting library expects all the four-node shell elements to work in the same way but MVLEM-3D is different. I am working on a fix but will take some time.

from openseespy.

Yes I agree. A seperate package that has OpenSeesPy as a dependency would be better for development. This will make it easier for people contribute to the visualisation package as potentially a wider group of maintainers could be available for the visualisation since it is pure Python. Can also set up the visualisation package to auto build and deploy to Pypi if it passes its test suite on CircleCi using the following config: https://github.com/o3seespy/o3seespy/blob/master/.circleci/config.yml

from openseespy.

Agree too. Separate packages could has OpenSeesPy as dependency or receive a reference to OpenSeesPy which could be a self-compiled library. Each package maintainer will also have full control with versions and updates.

from openseespy.

I agree too. It's certainly the philosophy in the newer Julia ecosystem for packages to do one thing, and do it well. pymc3 is another example where they split off the visualization to the arviz package (and actually made that package more generally useful for visualizing outputs from other related packages).

FYI, why I'm on this thread is my research group is developing a package on top of OpenSeesPy for bridge deck analysis. So with this background, the key things from our perspective are:

• the stability of the OpenSeesPy API
• its comprehensiveness in interrogating native OpenSees objects (hence my interest in @sewkokot 's recently added functions, #69).
• Quick integration of higher-level (i.e. post-processing) tweaks/additions.

So an OpenSeesPy that is stable, 'complete', and infrequently changing, coupled with a nimble post-processing package with CI would be perfect from our perspective! And we'll be pleased to contribute to that goal.

I guess this approach would also support other package development in the OpenSees ecosystem, such as @millen1m 's O3seespy?

from openseespy.

I agree, as well. In fact, I remember last year, before sending an ops_vis PR to OpenSeesPy and OpenSeesPyDoc I had tested the ops_vis module in a separate github repository [1] and a readthedocs documentation [2].

I have also made tests of ops_vis at PyPi-test [3] to ensure everything works correctly. So more or less I'm prepared to this change, which should facilitate the development of pre and postprocessing packages.

Does this also mean that you remove the documentation of the visualization packages from OpenSeesPyDoc [4] and only links to separate documentation pages will be provided there?

[1] https://github.com/sewkokot/ops_vis
[2] https://ops-vis.readthedocs.io/en/latest/
[3] https://test.pypi.org/project/ops-vis-sewkokot/
[4] https://openseespydoc.readthedocs.io/en/latest/src/postprocessing.html

from openseespy.

I agree with this approach. This will also help the visualization packages to include other dependencies (vtk, gmsh, etc.) which the OpenSeesPy core repo wouldn't prefer.

from openseespy.

I think this is a great idea.
Even though it's not as powerful as Tk, python is sure making pre/post-processing a lot easier to build. A version of OpenSeesPy that is as light and robust as possible would be ideal.
@ccaprani , you moving to Julia?

from openseespy.

Hello, I have a question about the plot of the new MVLEM_3D element, I have been doing some testing with the command openseespy.postprocessing.Get_Rendering.plot_model() and the elements are observed as sand clocks... I would like to know whether it is an error of the element or it is an error of plot_model(), and how to fix it.
I attach an example code with the comparison of the plot of ShellMITC4 element.

#INSTALACIÓN DE LIBRERÍAS
import openseespy.opensees as ops
from openseespy.opensees import *
import openseespy.postprocessing.Get_Rendering as opsplt
import matplotlib.pyplot as plt

#SISTEMA DE UNIDADES
##Unidades Base
m = 1
kg = 1
s = 1
##Otras Unidades
cm = 0.01*m
N = kg*m/s**2
kgf = 9.81*N

ops.wipe()
ops.model('basic', '-ndm', 3, '-ndf', 6)

#Nodos
ops.node(1, 0, 0, 0)
ops.node(2, 2, 0, 0)
ops.node(3, 0, 0, 3)
ops.node(4, 2, 0, 3)

ops.node(11, 3, 0, 0)
ops.node(12, 5, 0, 0)
ops.node(13, 3, 0, 3)
ops.node(14, 5, 0, 3)

#Materiales
##Concreto
fc = 210*kgf/cm**2
E = 15100*(fc/(kgf/cm**2))**0.5*kgf/cm**2
G = 0.5*E/(1+0.2)
ρ = 2400*kg/m**3

ops.uniaxialMaterial('Elastic', 1, E) #Concreto Axial
ops.uniaxialMaterial('Elastic', 2, 2*10**6*kgf/cm**2) #Acero
ops.uniaxialMaterial('Elastic', 3, G) #Concreto Cortante

#Muro 1 MVLEM_3D
ops.element('MVLEM_3D', 1, 1, 2, 4, 3, 1, '-thick', *[0.15], '-width', *[2], '-rho', *[0], '-matConcrete', *[1], '-matSteel', *[2], '-matShear', 3, '-Poisson', 0.2, '-Density', ρ)

#Muro 2 ShellMITC4
ops.section('ElasticMembranePlateSection', 10001, E, 0.2, 0.15, ρ)
ops.element('ShellMITC4', 2, 11, 12, 14, 13, 10001)

opsplt.plot_model()
plt.show()

from openseespy.