Do we still have the non-elegant non-array/matrix non-Num/Scipy loopy version of horizontal modal somewhere? This will remove one xfunc call in the Grasshopper wrapper and save a couple of seconds per solve.

Because the latest exciting revision of TNA only draws the interior vertices of the FormDiagrams as faces in the ForceDiagram, and therefore include only the spaces surrounding these nodes as vertices in the ForceDiagram... and because ForceDiagram's keys are drawn directly from FormDiagram's keys... the mapping between vertex key and index in the ForceDiagram is more necessary than ever.

Consider inserting:
_edges = [[_k_i[u], _k_i[v]] for u, v in _edges]

As is already the case in horizontal_numpy...

Feature Request

The faces of the Mesh have a useful attribute 'is_loaded' that can be used to set up openings in a form-diagram. However when this attribute is modified, the tributary area of the adjacent vertices obtained with the method Mesh.vertex_area() are not updated.

Details

In the code below, I check the vertices of a given mesh.face and I verify that it is set with 'is_loaded' attribute = True. However by changing this attribute to 'is_loaded' = False the vertex_area of all nodes that should be affected is not updated.

>>> form.face_vertices(1)
[0, 1, 3]
>>> form.get_face_attribute(1, 'is_loaded')
True
>>> form.vertex_area(0)
0.4589925871968803
>>> form.vertex_area(1)
0.6083146245381257
>>> form.vertex_area(3)
1.3466022185558575
>>> form.set_face_attribute(1, 'is_loaded', False)
>>> form.get_face_attribute(1, 'is_loaded')
False
>>> form.vertex_area(0)
0.4589925871968803
>>> form.vertex_area(1)
0.6083146245381257
>>> form.vertex_area(3)
1.3466022185558575

Describe the solution you'd like
What is the best way to update these tributary loads easily?

Which feature can be added?
I think it make sense that when .vertex_area() is called it consider only the adjacent faces that have the parameter 'is_loaded': True. Other alternative would be introducing a method .tributary_area() possibly considering this options. What do you think?

Thanks!

examples of items that cannot be imported:
TPL
mesh_smooth_area
network_find_face

etc etc

Feature Request

It would be useful to have a more transparent way to add the feets to both cases:

1. Close network (contain the edges in the boundaries), should receive information of which node add the feet to.

2. Open network (containing leaves), should automatically consider the feets as the leaves unless explicitly said so....

   2.1) User should be able to input an open network by considering still a "closed network" in which the edges in the boundary become 'is_edge': False

3. Option to do it manually... Which parameters have to be set to achieve a sort of 'is_feet': True

As a robust target-lengths-agnostic paralliesation method based on best-fit multi-line intersection...

ForceDiagram.ordered_edges() ignores FormDiagram's edges' 'is_true' attributes

Suggest changing
edges = [index_uv[index] for index in range(self.number_of_edges())]
to
n_form_true_edges = len(list(form.edges_where({'is_edge': True})))
edges = [index_uv[index] for index in range(n_form_true_edges)]

(1) It would be great to have boundaries identification methods for FormDiagrams with GS-induced elements that (as an option) can identify the boundaries associated with the pre-GSified-mesh (in other words, the option to find the boundaries of form diagrams whereby the unloaded faces lining the unsupported edges, feets once upon a time, and any other non-physical elements to be introduced in future compas_tna are removed).

(2) Ditto for metrics like number_of_x() that can discount the non-physical GS-induced elements (e.g. edges that are not edges)

(3) On a related note, it would be great to have methods that can easily revert a form diagram to its pre-GSified mesh.

Hello,

The display for print the number of iterations was solver for the horizontal equilibrium, but not when using the horizontal_nodal solver.

This calls for the function parallelise_nodal that has no attribute 'display'. Can we either comment it out or add attribute 'display' to this function?

Gracias!
Ricardo

suggest ForceDiagram to inherit from FaceNetwork, as opposed to Network
this will provide the ForceDiagram with face methods, which enhances the ability for design driven by force diagram manipulation, such as subdivision

Edge length attribute of force diagram is not updated when horizontal equilibrium is solved for.

Revisiting TNA this month because I am attempting to wrap some of the core features in Grasshopper for our workshop. However, I noticed that the example files are no longer working. The viewers are gone and the vertical equilibrium methods are also having issues.

label dual elements

It could be useful to have a function to show the form and the force diagram together with the dual elements labelled so that it is easy to see read them

def vertical_from_q
line 246:

change
form.edge_attributes(edge, '_f', f[index, 0])
to
form.edge_attribute(edge, '_f', f[index, 0])

When trying to count the dof, gets the following error

File "C:\compas_tna\src\compas_tna\utilities\diagrams.py", line 55, in count_dof
xyz = form.xyz()
AttributeError: 'FormDiagram' object has no attribute 'xyz'

The current convention for qs in RV2 is: positive for compression and negative for tension.

FormFinder uses the opposite convention.

As the plugins will soon operate under the same environment based on compas_ui where the meshes will be exchanged from one plugin to the other, this convention should be consistent.

The dots are showing the current q values.

In other contexts after the vertical equilibrium it may be useful to keep the qs that resulted in the required height.

attr['q'] = attr['f'] / form.edge_length(u,v)
or
attr['q'] = f[index, 0]

Is that any reason why we don't store the 'q's?

Feature Request

I would suggest that we take out the unnecessary plots on the iterations for functions "horizontal" and "horizontal_nodal".

Also, I miss the nice plots of form and force that were able before on the package so we can easily visualise equilibrium.

Thanks.

While author understands the reasoning behind this, the auto-removal and -disabling can cause disruptions... (for instance, users may use corners as key markers/datums, etc....)

please check all equilibration methods involving numpy
as an example:

this is to ensure that attributes are not np.float64 but float
so that the form diagrams can be json-serialisable, and therefore makes it possible for form diagrams to be saved.........................................................................................

Suggesting the ability to decide whether uv_index in FormDiagram.uv_index() includes/excludes edges with True/False 'is_edge' attributes.

Moving from .rui -> ETO ui

there's a method rui_make that generates a .rui file, a toolbar that calls python scripts. In summary hitting a button invokes a macro.

Details

Is your feature request related to a problem? Please describe.

( I'm making some assumptions here, I hope these are correct. Havent utilized the toolbar since working from RhinoMac )

I suspect that each time an macro is invoked, the python script has to load a cached .json file, or loads geometry stored in designated layers. That is the state of the program isnt kept in memory, but is being rebuild.

So the hunch here is that creating a ETO based UI is low hanging fruit, also since the actions already defined are easily hooked to such an ETO based UI. The upside here is that while the UI loop is running, the TNA mesh is kept in memory, hence quite a boost in responsiveness is to be expected

That stated, stoked to read the crisp and clean compas_tna code!

Is your feature request related to a problem? Please describe.
My problem is i cannot find any exe files for installation of rhinovault2 in github, instead there is "compas_tna_-0.4.0", different type of file. So i installed the rhinovault2 plugin in eth website, but it doesn't work in rhino 8(student version).
Specifically, i have loaded rhinovault2 in rhino8 version however, i cannot find toolbars.
Another problem was all plugin command names have been changed compared to
https://www.youtube.com/watch?v=k6vKHs5YinI, which i used as a tutorial for RV2.

Describe the solution you'd like
I would like to get exe file for RV2 and give us manual pdf for the lastest version. (for example, there are no "make(create)pattern" command and "rvdefineboundaryconditions")

Additional context
Thank you for sharing these interesting plugins.

Because of the awful, but ultimately reasonable decision made here:

compas-dev/compas#127

update boundaryconditions.json to form_boundaryconditions.json

Message: 'FormArtist' object has no attribute 'datastructure'.

settings = {
'show.forces' : True,
'show.reactions' : True,
'scale.forces' : 0.02,
'scale.reactions': 1.0
}

form.draw(layer='TNA::Vault', clear_layer=True, settings=settings)

Comment regarding the 'horizontal_nodal' method.

Shouldn't the l and _l be recompute after the parallelise_nodal operation, especially if the form and force diagram's xy positions have changed and the algorithm relies on l to compute q?