Location / Identification for grid specs outside of a file

As we all know, CF data (or model results, anyway) are often associated with a particular grid specification.
This could be a simple rectangular grid, or a more complex grid, such as those  defined by the UGRID and SGRID specs.
It's a common practice to store the grid definition in the same file as the data itself, which works out fine. But in some cases, the grid specification may be substantial, and so it can be stored in a separate file, so it doesn't need to be repeated.
In that case, there needs to be some way to find that other file, and, ideally, determine that it is, indeed, the correct grid. Various folks are doing this already, but not in a standard or robust way -- so It would be nice to have an standard way to do that in CF.
I'm pretty sure I recall some previous discussion about this, but was not able to find it -- thus the new issue.
But please feel free to redirect this discussion to an existing issue if there is one.
I bring this up now because there was a proposal on the UGRID spec site:
https://github.com/ugrid-conventions/ugrid-conventions/issues/59
But it would really be nicer to have a way to do that for any grid type in CF itself.
I refer you to that discussion for a more fleshed-out idea. If the UGRID community wants to take this up, I recommend we move the discussion from the UGRID repo to here.

https://cfconventions.org/Data/Trac-tickets/145
V. Balaji                              Office:     +1-609-452-6516
Advanced Computing Projects            Mobile:     +1-917-273-9824
CIMES/GFDL                             Email:
@.***://www.gfdl.noaa.gov/v-balaji-homepage
On Thu, Mar 10, 2022 at 1:58 PM Chris Barker @.***>
wrote:

As we all know, CF data (or model results, anyway) are often associated
with a particular grid specification.
This could be a simple rectangular grid, or a more complex grid, such as
those defined by the UGRID and SGRID specs.
It's a common practice to store the grid definition in the same file as
the data itself, which works out fine. But in some cases, the grid
specification may be substantial, and so it can be stored in a separate
file, so it doesn't need to be repeated.
In that case, there needs to be some way to find that other file, and,
ideally, determine that it is, indeed, the correct grid. Various folks are
doing this already, but not in a standard or robust way -- so It would be
nice to have an standard way to do that in CF.
I'm pretty sure I recall some previous discussion about this, but was not
able to find it -- thus the new issue.
But please feel free to redirect this discussion to an existing issue if
there is one.
I bring this up now because there was a proposal on the UGRID spec site:
ugrid-conventions/ugrid-conventions#59
https://github.com/ugrid-conventions/ugrid-conventions/issues/59
But it would really be nicer to have a way to do that for any grid type in
CF itself.
I refer you to that discussion for a more fleshed-out idea. If the UGRID
community wants to take this up, I recommend we move the discussion from
the UGRID repo to here.
—
Reply to this email directly, view it on GitHub
https://github.com/cf-convention/cf-conventions/issues/357, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQJZVGGJF4YVCI5PVHVBF3U7JA6LANCNFSM5QNQN6QQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

THanks -- looking at that issue, it resulted in this in teh current standard:
"""
2.6.3. External Variables
The global external_variables attribute is a blank-separated list of the names of variables which are named by attributes in the file but which are not present in the file. These variables are to be found in other files (called "external files") but CF does not provide conventions for identifying the files concerned. The only attribute for which CF standardises the use of external variables is cell_measures.
"""
Which is clearly similar / related, but doesn't help with the issue at hand - particularly as it is restricted to cell_measures.
IN a sense, this is a broader problem -- we're not talking about refereing to particular variable per-se, but to an entire grid definition -- a concept that may not yet be included in CF, but will if/when UGRID is included.
So maybe we should talk about this in: #153 ?

@ChrisBarker-NOAA  Has this discussion progressed anywhere else? I see the UGRID ticket is waiting on us (CF). I think it would be entirely proper to make a proposal which is a variant on the external measures option 2.6.3, but which provides a UUID as well as a variable name for the variable in another file.

Hello @ChrisBarker-NOAA, @JonathanGregory and All,
I am keen that this is pursued, but only for UGRID mesh topology variables and the variables that they reference (such as connectivity variables). To that end @bnlawrence, @koldunovn and myself have been working on an encoding proposal, and are close to actually proposing it. As @JonathanGregory suggests it could be, our proposal it quite simple and includes an extension of the existing external_variables functionality.
Why only for UGRID? Apart from it being the only use case on the table (as far as I'm aware), and there are complications if it is extended to arbitrary domain definitions. These complications arise from having to think about whether or not a data variable can be allowed to reference a domain variable instead of the usual collection of metadata variables via named attributes (coordinates, cell_measures, etc.). Our proposal is independent of this complication (due to the nature of the UGRID encoding), so a future extension to address it would certainly be possible.
Many thanks,
David

Why only for UGRID?

Makes sense, though:

there is also SGRID (https://sgrid.github.io/sgrid/) which may someday make it's way in.
even though "ordinary" grids like rectangular, etc, are not defined by a single variable in the way UGRID is -- it is still the case that the grid variables. can be quite large, and would benefit from being able to be stored separately and referenced.

So: Yes, only for UGRID now, but let's make sure to leave the door open for extending it to other grid types in the future.

Hi Chris,

there is also SGRID (https://sgrid.github.io/sgrid/) which may someday make it's way in.

Absolutely. If/when SGRID makes it into CF, external variables could be extended to include it. To be discussed at that time.

even though "ordinary" grids like rectangular, etc, are not defined by a single variable in the way UGRID is -- it is still the case that the grid variables. can be quite large, and would benefit from being able to be stored separately and referenced.

Indeed, large "ordinary" grids could well benefit from this. I think that is better dealt with separately because a) no one is actually asking for it right now, and b) even if they were, it will involve a discussion (instigated by me :)) on whether to allow domain variables to be referenced from data variables - this discussion is not relevant to UGRID, so would only hold up the current discussion, which does have an existing use case.
I'm not expressing an opinion either way on ordinary grids - just kicking the can down the road for now!

So: Yes, only for UGRID now, but let's make sure to leave the door open for extending it to other grid types in the future.

Good. Are you happy for me put in PR linked to this issue that I have ready that could implement this?
Thanks,
David

Absolutely—go for it.

Thanks Chris. Here is a proposal ...
Allowing UGRID mesh variables to be external
Moderator
To be decided.
Moderator Status Review [last updated: YYYY-MM-DD]
Requirement Summary
For data defined on UGRID mesh topologies, it is already the case that datasets are being written for which the mesh variables, i.e. the mesh topology variable and all the variables that it references (e.g. the node coordinates), are stored in a different netCDF file to all of the data variable files. This is because the UGRID description of a mesh can be very large in terms of the disk space required to store it, so repeating it in every file can be expensive. For instance, depending on how many of the optional (yet useful) UGRID features are included, the specification of mesh faces can be approximately 6 to 20 times larger than a 1-d data array defined on those faces.
The mechanism for allowing the mesh variables from one file to be associated with the data variable in another file needs to be standardised so that users of the data can correctly interpret such dataset, and generic software applications can be built that can facilitate the recombination of data and metadata.
Cell measures: A bit of history
CF-1.7 introduced the concept of external variables, but only for cell measures (Section 2.6.3. External Variables). The motivation for the cell measures case was to save space, and it was already been done in a non-standardised way prior to CF-1.7. In other words, the pragmatic situation and motivation for allowing cell measures to reside in an external file are the same as for mesh topology variables. The discussion on allowing cell measures to be external (Trac ticket #145):

Acknowledged that ideally external files would not be allowed, i.e. all metadata is always in the same files as the data it describes.

Acknowledged that saving space is a valid use-case, and that petabytes of data already existed (CMIP5), and will continue to be produced (CMIP6), with non-standardised storage of cell measures in external files.

Carefully considered whether or not to allow other types of metadata that define the cell locations to be be external (such as coordinate and auxiliary coordinate variables, grid mapping variables, etc.). It was pointed that the purpose of CF (Section 1.1. Goals) is to define the necessary elements of a netCDF file such that conforming files "contain sufficient metadata that they are self-describing in the sense that ... each value can be located in space and time", and therefore any information that is needed to geolocate the data must go in the file itself. There was no real disagreement with this, and the cell measures use case did not overlap with geolocation, so it was agreed to restrict external variables to cell measures.

Why allow mesh-related variables to be external, but not arbitrary geolocation variables?
Whilst being able to put arbitrary geolocation variables in external files has been talked about for years, there are technical aspects that have not been addressed which do not apply to UGRID meshes  (such as whether or not to allow data variables variables to reference domain variables), and it is the UGRID mesh use case that is being actively discussed here. Restricting the proposal to UGRID meshes will not directly impact on any future discussion on a use case for a further generalisation of external variables, so there is no need to complicate the current situation.
Functional summary
We propose extending the attributes for which CF standardises the use of external variables to include mesh, the attribute that references a UGRID mesh topology variable from data, domain and UGRID location index set variables. The variables referenced by the external mesh topology variable (such as the node coordinate variables) must also listed as external variables.
In addition we propose a simple mechanism to better prevent an incorrect external variable being used by mistake. A new optional global attribute will allow an arbitrary string-valued identity to be associated with each external variable. When provided, and the same identity is also given as an attribute of the external variable in the external file, then the identities must match for the external variable to be used.
Technical Proposal Summary
Allowing meshes to be external
Extending the attributes for which CF standardises the use of external variables to include a mesh topology variable will follow the same principle as for external cell measure variables, with additional rules concerning the variables that the mesh topology variables refers to.
The first (and currently only) paragraph of Section 2.6.3 External Variables will be changed to:
An "external variable" is one which is named by an attribute in the file but which is not present in the file. These variables are to be found in other files called "external files". A variable named by an attribute of an external variable must also be an external variable. CF does not provide conventions for identifying external files, but an external variable must be in the same external file as any variables named by its attributes. The only attributes in the file for which CF standardises the use of external variables are cell_measures and mesh. External variables are provided by the global external_variables attribute, which is a blank-separated list of external variable names, none of which are allowed to be coincide with the name of any variable in the file.
Providing identifiers for external variables
The following paragraph will be inserted at the end of Section 5.9 Mesh Topology Variables:
A mesh topology variable referenced by the mesh attribute is not required to be present in the file containing the data, domain or location index set variable. If the mesh topology variable is located in an external file, rather than in the file where it is referenced, it must be listed in the global external_variables attribute of the referencing file (Section 2.6.3). All variables referenced by an external mesh topology variable, such as connectivity and node coordinate variables, must also be listed in the external_variables attribute, and must be located in the same external file as the mesh topology variable.
Providing identifiers for external variables
The following new paragraph will be inserted at the end of Section 2.6.3. External Variables:
A variable listed in the external_variables attribute may optionally be associated with an arbitrary string-valued "identifier" which provides a secondary mechanism, after the variable name and the names of its dimensions, for finding the correct external variable. The global external_variable_identifiers attribute defines the identifiers for any subset of the external variables. This is a string attribute comprising a list of blank-separated pairs of words of the form "variable: identifier". The "variable" is the name of an external variable, and the "identifier" is the variable's identifier. When an identifier has been provided by the external_variable_identifiers attribute, a program application that also has access to the external file should only use the corresponding external variable if it has the same identifier defined by its string-valued variable_identifier attribute. When a variable listed in the external_variables attribute does not have a corresponding external identifier in the external_variable_identifiers attribute, then any external variable with the correct name and dimensions may be used.
Examples
A new example for Section 2.6.3. External Variables:
Example 2.2: A file with external variables
dimensions:
  nFace = 5839 ;
  time = 12 ;
variables:
  double time(time) ;
    time:standard_name = "time" ;
    time:units = "days since 2000-01-01" ;
  double u(time, nFace) ;
    u:standard_name = "eastward_wind" ;
    u:units = "ms-1" ;
    u.cell_measures = "area: cell_areas" ;
    u:mesh = "mesh" ;
    u:location = "face" ;

// global attributes:
    :external_variables = "cell_areas
                           mesh
                       	   node_lon node_lat
                       	   face_nodes edge_nodes face_edges face_links edge_face_links" ;
    // Optional external variable identifiers
    :external_variable_identifiers = "cell_areas: ae45-ed12b mesh: 9ed4-83f46" ;

Example 2.3: The external file containing the external variables for example 2.2
dimensions:
  nNode = 3140 ;
  nEdge = 8986 ;
  nFace = 5839 ;
  n2 = 2 ;
  n3 = 3 ;
variables:
  // Cell measure variable (could be in a different file to the mesh variables)
  double cell_areas(nFace) ;
    cell_areas:variable_identifier = "ae45-ed12b" ;  // Optional variable identifier
    cell_areas:standard_name = "cell_area" ;
    cell_areas:units = "m2" ;

  // Mesh topology variable
  int mesh ;
    mesh:variable_identifier = "9ed4-83f46" ;  // Optional variable identifier
    mesh:cf_role = "mesh_topology" ;
    mesh:long_name = "Topology of 2D unstructured mesh" ;
    mesh:topology_dimension = 2 ;
    mesh:node_coordinates = "node_lon node_lat" ;
    mesh:face_node_connectivity = "face_nodes" ;
    mesh:edge_node_connectivity = "edge_nodes" ;
    mesh:face_edge_connectivity = "face_edges" ;
    mesh:face_face_connectivity = "face_links" ;
    mesh:edge_face_connectivity = "edge_face_links" ;

  // Variables referenced by the mesh topology variable (must be in the
  // same file as the mesh topology variable)
  double node_lon(nNode) ;
  double node_lat(nNode) ;
  int face_nodes(nFace, n3) ;
  int edge_nodes(nEdge, n2) ;
  int face_edges(nFace, n3) ;
  int face_links(nFace, n3) ;
  int edge_face_links(nEdge, n2) ;

Updating appendix A: Attributes
The new attributes  external_variable_identifiers and  variable_identifier will be included in Appendix A: Attributes, with usage "G" (global) and "CM, U" (new designations for cell measure variables and UGRID variables) respectively.
Benefits
All users of datasets with external meshes would benefit from this proposal.
Status Quo
Users of datasets with external meshes will struggle to read datasets with external meshes.
Associated pull request
Not yet written, but all changes are detailed above.

Dear @davidhassell
Thanks for this proposal, which I think is sound and sensible. I have only one minor comment, namely that I wonder if the attribute variable_identifier could be just identifier. Since it's attached to a variable, it hardly seems necessary to state variable, and moreover there's even a small possibility of confusion, from misunderstanding variable as an adjective. It corresponds to external_variable_identifiers, which I would parse as external_variable + identifiers.
Best wishes
Jonathan

Thanks for looking at this, @JonathanGregory.
I agree with your suggestion on the name of the external variable identifier attribute (i.e. calling it identifier as opposed to "variable_identifier").
Given this initial support, I shall create an actual PR with the above changes, incorporating Jaonthan's suggestion.

Whilst writing the external variables PR, I came up with some better (?) text for Section 2.6.3, which is, in full:
An "external variable" is one which is named by an attribute in the file but which is not present in the file, or is named by an attribute of another external variable. These variables are to be found in other files called "external files". An external variable must be in the same external file as any variables named by its attributes. The only attributes in the file for which CF standardizes the use of external variables are cell_measures and mesh. External variables are provided by the global external_variables attribute, which is a blank-separated list of external variable names, none of which are allowed to coincide with the name of any variable in the file.
CF does not provide conventions for finding external files, but once an external file for an external variable has been located it is expected to contain a variable with the same name; and the names of the variable's dimensions (if any) are the same as the corresponding dimensions in the parent file, and with the same sizes. An additional check that an external variable is the correct one may be optionally provided via an external variable identifier. The global external_variable_identifiers attribute defines identifiers for any subset of the external variables. This is a string-valued attribute comprising a list of blank-separated pairs of words of the form "variable: identifier", where variable is the name of an external variable, and the identifier is the external variable's identifier. When an identifier has been provided by the external_variable_identifiers attribute, a program application that also has access to the external file should only use the corresponding external variable if it has the same identifier defined by its string-valued identifier attribute. When a variable listed in the external_variables attribute does not have a corresponding identifier in the external_variable_identifiers attribute, then any external variable with the correct name and dimensions may be used. Note that a variable referenced by an attribute of an external variable does not benefit from having an identifier, because it must always be in the same external file as its parent external variable.

A couple comments:

An additional check that an external variable is the correct one may be optionally provided via an external variable identifier.

I presume this has been hashed out previously, but are we sure we want the identifier to be optional? That seems like a really good idea, why not require it?
(client code could ignore it of course...)
The other thought in that is whether some guidance should be provided on the the identifier -- ideally it would be likely (or guaranteed to be) unique:

a UUID?
A hash of the variable?
A long and meaningful name

Maybe that's too much to require, but it could be suggested. My concern is that we'll end up with identifiers, like FVCOM-mesh or the like, or even "mesh"

Then any external variable with the correct name and dimensions may be used.

given that the mesh variable is always the same dimensions, and names like "mesh" are likely -- that does reinforce why an identifier is a really good idea!
In practice, for a UGRID,  the wrong mesh definition is highly unlikley to be compatible with the other variables, but it would be better to fail early.
-CHB

Dear David
Your text is clear, thanks, except that I think this sentence could be improved

CF does not provide conventions for finding external files, but once an external file for an external variable has been located it is expected to contain a variable with the same name; and the names of the variable's dimensions (if any) are the same as the corresponding dimensions in the parent file, and with the same sizes.

I suggest the following, if it's correct

Users of data must rely on their own means to locate the external files that they need, because CF does not provide conventions for finding external files. The external file supplying an external variable of a given name must contain a variable of that name, whose dimensions (if any) in the external file must have the same names and sizes as the corresponding dimensions in the parent file.

Cheers
Jonathan

Following @ChrisBarker-NOAA's comment, I suggest we could strengthen

An additional check that an external variable is the correct one may be optionally provided via an external variable identifier.

to

To enable an optional additional check that the external variable is the correct one, it is recommended to provide the external variable with an identifier.

We should say here what format this identifier can have. Since they're containing in a blank-separated list, each identifier must be a single word not containing any whitespace. It doesn't have to be intelligible text, but if it's contained in a string I suppose it ought to be consist of printable ASCII characters only i.e. hex 21-7E inclusive. Is that too restrictive? I agree with Chris that we could give some guidance about choosing the identifier, along the lines that to fulfil its purpose it should somehow distinguish among variables that have the right name and shape in the set of files which the user program might consider, so it probably won't help if it's always given the same name by a given program writing datasets of this kind.
Best wishes
Jonathan

Hi Chris, thanks for your feedback.

I presume this has been hashed out previously, but are we sure we want the identifier to be optional? That seems like a really good idea, why not require it?

This has not been thrashed out in public before. Off-line @bnlawrence and I have talked about it whilst preparing this, but didn't come to a consensus. I favour optional, but Bryan mandatory. My reasons are for optional are:

External variables have existed for some time for cell measures, so it is preferable for the identifier to me optional because CF prefers that metadata written according to previous versions of the convention should also be compliant with and have the same interpretation under later versions.
CF allows creators to store the data that they want to and generally doesn't prescribe what they should do.

I'm not worried about people not providing identifiers simply because they don't have to - standard_names are (almost) never required, but they are used because people want to, for whatever motivation (they can see that they're useful, or their project insists on them, etc.)
We could certainly recommend that people use an identifier though, then the CF checker will warn in it's absence for files from CF-1.12 onwards.
I hope that Bryan will chime in with his point of view :)
I'm happy leaving the content of an identifier unrestricted (though with @JonathanGregory's caveats) - I can see use cases for a UUID and  for a nice name like "CMIP6-HadGEM3-N96-cell-areas".

Ah, at last, my chance to air my opinion, and without seeding the conversation first! Thanks @ChrisBarker-NOAA !
I think we should :
a) make it not just a string identifier but a UUID string identifier, and
b) it should be compulsory.
a) would nearly guarantee uniqueness (you couldn’t get in trouble later on because someone copied a different grid into the same path and filename on your machine), and
b) would make sure that it worked as intended - without it, it's basically fragile beyond belief. We get away with areacella because only a tiny fraction of applications need it  ...

Dear all
I agree with @davidhassell that the new identifier attribute should not be mandatory, for the reasons he states, following CF design principles 9 and 8 (sect 1.2). I think a recommendation to include it is sufficient.
I like Bryan @bnlawrence's idea of using a "universally unique identifier" UUID. For the sake of anyone who, like me, didn't know what this is, wikipedia says

A Universally Unique Identifier (UUID) is a 128-bit label used for information in computer systems. The term Globally Unique Identifier (GUID) is also used, mostly in Microsoft systems.

When generated according to the standard methods, UUIDs are, for practical purposes, unique. Their uniqueness does not depend on a central registration authority or coordination between the parties generating them, unlike most other numbering schemes. While the probability that a UUID will be duplicated is not zero, it is generally considered close enough to zero to be negligible.

Thus, anyone can create a UUID and use it to identify something with near certainty that the identifier does not duplicate one that has already been, or will be, created to identify something else. Information labeled with UUIDs by independent parties can therefore be later combined into a single database or transmitted on the same channel, with a negligible probability of duplication.

Adoption of UUIDs is widespread, with many computing platforms providing support for generating them and for parsing their textual representation.

In that case, the identifier would be a string consisting of hexdigits and a few allowed punctuation marks. Also, we could call the attribute uuid instead of identifier. I agree with David that there is an appeal in having a meaningful text string as an identifier, and that's consistent with CF providing self-explanatory metadata. However, if the identifier is required to be an opaque string, the data-writer could instead make the variable self-explanatory by, for instance, giving it a long_name to say what it's for, or a self-describing variable name. CF attaches no meaning to variable names, but humans can!
Cheers
Jonathan

I'm only superficially familiar with uuid, but in CMIP we require each file to include a global attribute we call "tracking_id", and it contains a prefix plus a uuid constructed as described here:
tracking_id should be of the form “hdl:21.14100/”  (e.g., “hdl:21.14100/02d9e6d5-9467-382e-8f9b-9300a64ac3cd”).  The tracking_id should be unique for each file published in ESGF.  The  should be generated using the OSSP utility which supports a number of different DCE 1.1 variant UUID options.  For CMIP6, version 4 (random number based) is required.  Download the software from http://www.ossp.org/pkg/lib/uuid/.

Dear all
On further reflection, while walking home, I've changed my mind to agree with @davidhassell that sometimes it would be better to have a meaningful identifier, rather than a UUID. It's a good idea to use a UUID when the external variable could take many different values, such as time-dependent cell metrics. On the other hand, for static information, such as David's example of CMIP6-HadGEM3-N96-cell-areas and the CMIP areacella and areacello variables, an external variable with the same content might be stored in various files, generated at different times, and any of them would be acceptable. It would be obstructive to insist that you used a particular one of them, which might perhaps not even be available to you. That would lead to the convention being ignored in practice.
This consideration suggests we should leave it to the data-writer to decide what's sensible, and give them guidelines. The identifier should not have a generic value like areacello, but if the data-write can choose a meaningful string which they're confident would only be used for the same contents of the external variable, that's fine. If they can't have such confidence, a UUID would be a good choice.
Best wishes
Jonathan

Following the CMIP example, you could have the best of both worlds by using an attribute with a value like meaningful_identifier/uuid.  I agree that it makes sense to leave it up to data-writers to decide what makes the most sense, but perhaps we could recommend that as the default?

hi Everyone
I knew that suggesting something would be mandatory would be controversial, but up until now, it has been mandatory to put the coordinate information in the file, indeed our "primary principle" has been "Data should be self-describing, without external tables needed for interpretation." and unlike areacella which is mostly not needed for interpretation, one will not be able to interpret these files without the external information.
The suggestion that unavailability of specific files would cause problems is, I think confusing information with usage. I think the use of a uuid makes it possible for software to be sure that the coordinate file is the correct one - but if you haven't got access to it, software can be advised to use a different one - which puts the onus on the human advisor to get it right.
Given that these files will always be created by software, it will not be onerous to require a UUID at creation time - what one does when confronted by the lack of the appropriate file at usage time should be up to a human.
What this discussion has made me change my mind on is that it would be desirable to have both a UUID and a human readable identifier.

(I should say that one might imagine the appropriate coordinate files could be distributed with standard configurations of the code so while there is a risk of many files with the comment and different UUIDs this is a risk that can be mitigated against. But this is the risk which is most likely to cause me to disagree with myself if someone can convince me.)

Agreed.  So at data writing time there are two choices:

we know there is an existing unique identifier to the domain of interest - and most likely we actually have that domain coordinate file - so we use that (if we write our own copy using a pre-existing identifier I'd rather like it to be best practice to add metadata to say that has been done), or
we don't know an existing unique identifier, so we write our own to go with our own copy of the domain description, and then write the data with that.

At reading the data time, there are two choices:

We have the domain description file which matches the unique identifier and are good to go, or
We have a domain description file which we believe to be correct, but the unique identifier doesn't match, we may have reason to trust that it is appropriate to use this, so we proceed with caution.

many thanks all for raising this issue's profile and exploring opportunities to progress this.
I can see the utility of such an approach.
There is an aspect I am cautious of, which I would like to explore, if I may?
Firstly, context & support:
I believe that the only facet in the current conventions is the the global attribute external_variables.
This appears to provide a blank-separated list of attribute names that are used within the file, but are not able to be referenced within the file.  This is important information to provide to file parsing tools, to help them function efefctively.
Extending the use of this attribute to the use case presented here seems completely sensible to me.
However, I am a bit more cautious about the limited scope of the proposed external_variable_identifiers attribute.
This appears to only give one opportunity to provide one string item of identifying information about each external variable.
Yet, there may be multiple useful pieces of information that a data provider could supply that would build robustness into the external referencing, and mitigate the risk that data is provided without access to the essential coordanite information, rendering the data unusable.
The UGRID case is particularly interesting, as well as useful, as we are likely exploring putting numerous external variables within a single file / object to describe the unstructured domain. So, should we be thinking cautiously about how the data consumers need to act in identifiying the object to reference (a netCDF file, a data service endpoint, ...) and the specific variable set within that object, how to obtain that information at data read time, how to check intent, consistency?
Considerations on my mind include:

unique identification of a variable
human readable identification of a variable
unique identification of a file / object / endpoint which contains the variable
whether the variable has the same local name within the referenced file
a location which can be used directly to obtain a file / object / endpoint which contains one or more variables
any grouping of variables that are being externally referenced, e.g. in a single file
checksum of a file that contains a group of variables

(n.b. these are for context, I'm not asking that all of these be mandated; I'm hoping that they are illustrative of this being a multi-faced information requirement)

I am a bit concerned if there's only one item of information one can provide per variable, and the conventions only recommend this, and only tell us it may be a string-name, or a UUID or something else.
I think that there may be an opportunity to build a bit more robustness for this external referencing, without over-engineering the problem. Extensibility may be a useful characteristic here.
Are there options that we can explore, that are still scope constrained, but give opportunity for more than one piece of information to be encoded and provided per variable when describing external variables?

I don't see how you get from "it is mandatory when writing to" it is mandatory to use that information - that's akin to saying if I put both U and V in the file, you must use both!

It comes back to the "CF prime directive" - at the moment it is mandatory to put the domain IN the file (you could ignore that now if you wanted to).   I am suggesting that if you want to break the prime directive it should be mandatory to give users of that data the best possible chance of finding that information.

I don't see how you get from "it is mandatory when writing to" it is mandatory to use that information - that's akin to saying if I put both U and V in the file, you must use both!

I don't see it quite like that (today) - e.g. you can't ignore standard names, in that you can't treat a variable as eastward_wind if it has a standard name of air_temperature, however convenient that may be for you :-). By which I mean, if metadata (not variables) are provided then you can put minimum expectation on their use.

(I should add that I'm not entrenched here, just finding my way like the rest of us.)

I see that "forbid" was a poor choice of word - sorry! I meant that we can't say that providing an identifier is mandatory without also saying that a dataset is not CF-compliant if the external file doesn't also have a matching identifier. Otherwise I could just further game the system by putting in an arbitrary identifier in the parent file knowing that I never need to abide by it. In this situation CF-compliant software should refuse to entrain an external variable without a matching identifier.
This wasn't an argument against mandatory per se (although I still favour optional), rather an observation about the consequences of making it mandatory.
This is similar to some other of the few cases of mandatory attributes. E.g. the featureType attribute is mandatory for DSGs - if it is missing then in many cases software will fail to correctly parse the dataset - there's no scope for doing something else if it hasn't been provided.

I meant that we can't say that providing an identifier is mandatory without also saying that a dataset is not CF-compliant if the external file doesn't also have a matching identifier.

Of course, that is the idea, and true for any other requirement of CF - that's kind of the point :-)
It seems to me that CF is all about the data writer -- THIS is how you make your files properly described by metadata -- and it's guidance for data readers -- This is how you CAN interpret the metadata -- but, of course, we have no say whatsoever over what data readers actually choose to do -- if they want to ignore units, they can ignore units, or standard names, or whatever.

These files will always be created by software. Sometimes I have created cell measures files manually, when I could not obtain the "official" file (of areacella, areacello etc.) because of some technical nuisance, but I could deduce its contents from information from other sources.

Hmm -- it seems to me that in that case, your external file might , (or probably) would be the same -- but not actually guaranteed to be -- maybe only different to the tenth significant figure, or ... mayb eyou used a float32, and the original used a float64, or ....
So I would argue that it is not guaranteed to be the exact same information.
(if we want to, we could use a hash of the data (not the file, as metadata could change) to be a unique id of those exacty variables -- but in the example above, it probably wouldn't match.

If it was mandatory in CF to use a variable with the correct identifier, and cf-python implemented that requirement, I could only use my manually created file by manually writing the correct identifier in it i.e. spoofing the system.

I don't think so -- if you are creating that external file, then you create the identifier, and you point to it -- done. It may well be that there are other external files out there with the same information, but with different identifiers, but I think that's good, not bad.
I guess I'm missing something -- I can see two cases:

You have access to the external file when you create your file -- in which case you use the identifier it already has.

You don't have access to the external file, so you create it yourself. In which case you assign an identifier yourself, and use that. Which seems to me to the right thing to do.

How does leaving out the identifier help anyone here?
I think we have some consensus here:

An identifier should be likely to be unique, either:
a) a UUID or the like
b) A nice human readable descriptive name, maybe with a version, e.g. "SMAST_FVCOM_NECOFS_4.4.6"
(real example)

(whether we should specify A or B (or a combo) is still open)

An identifier is highly recommended.

The open question is whether it should be required or not.
My thoughts -- I'm having a really hard time finding any reason NOT to require it -- from a practical perspective, I see a LOT of files out there that are not quite strictly CF compliant (way too many :- ( ) -- so if someone really has a reason to not supply an identifier, they can not supply an identifier, and their file wont be fully compliant -- that's there choice.
NOTE on (1) above -- I don't think it's a deal breaker, but I'm trying to see how a compliance checker would enforce a "proper" identifier -- it can look like a UUID, but not actually be one, though maybe a warnign is enough -- "this doesn't look like unique identifier to me".
HMM -- I'm thinking of a realistic use case-- not sure how that impacts this issue:
It's quite common for the original provider to create a huge pile of file that all have the grid specification in them -- maybe one for each day, or each timestep, or ....
Then a downstream distributer (or more than one)  of the model. results may want to aggregate them in a particular way, and create an external grid definition file. The aggregator has the grid info, and can create an external file, and give it a unique identifier. All good and that aggregator can keep using that same external file as it ads to. the aggregation. All good.
But anyone else that is also aggregating, or is using the original files, will have no way to to know what. identifier anyone else is using -- so they will need to create their own, with their own identifier.
Is this a problem? Now that I've written it out, I don't think so -- and it's probably a good thing -- the only. way to know for sure that your grid matches your data is if they were, in fact, created in the same way from the same source -- so this is all a good thing. And, indeed, ideally, the original source would have provided an identifier for the grid, even if it wasn't in an external file :-)
I'm coming down on the mandatory side here. In short:
If we provide no way to locate an external file, and no way to know for sure that an external file you find is the right one, how in the world can we call that dataset self-describing?

Ah, that makes sense.  I disagree on only one point: I think CF-compliant software shouldn't automatically use external files without matching identifiers, but that it's reasonable for a user to override that manually.
The nature of external variables is that they've been separated out because they apply to multiple files, but that means there are cases where a user won't be able to get the external file and will need to either recreate it or provide something they can assert is functionally identical.  And although these cases will be (hopefully) rare, they're not impossible, and as Jonathan says, we don't want to force people to spoof UUIDs when that happens.

If we provide no way to locate an external file, and no way to know for sure that an external file you find is the right one, how in the world can we call that dataset self-describing?

In a similar way that CF allows minimal_dataset.nc.zip as a CF-compliant dataset:
$ ncdump minimal_dataset.nc
netcdf minimal_dataset {
variables:
	double foo ;
// global attributes:
		:Conventions = "CF-1.11" ;
data:

 foo = 4 ;
}
$

It's might not be very useful to some, is not very self describing, and would throw up a load of CF checker warnings (not errors), but it's OK!
CF provides has always provided the means for creators to describe their data, and for readers to interpret them as the creator intended. Should we make setting at least one of standard_name and long_name mandatory so that cases like the one above are not allowed? We could go even further and make other items mandatory (such as units and cell_methods, source, ...), however that's not what CF is today and I don't think we should be going down that road.
External variables have always been delivered with the expectation that the user should be careful to find the correct ones. The identifier is intended to make that choice easier in case that the data writer wants to be extra sure that appropriate variables are used, and in that case surely the writer would not want people to ignore the identifier?
If providing an identifier in the parent file were mandatory, then when the parent and external files are both passed to the CF checker, it would throw an error (not a warning) if the external file did not have the matching identifier. If we actually expect software to provide an "ignore identifier" option in the mandatory case, then we should in fact make the identifier optional so the data creator can say that they're happy for people to find/create their own, thereby preventing the need for software to provide a work-around that the data creator did not intend.
One of the reasons CF is successful is that it gives data writers freedom of expression with a well defined set of tools. We've seen that there are cases where flexibility is desired during the location of external variables, so we shouldn't force data writers to remove that flexibility when they don't want to. It's fine for CF to have an opinion (i.e. to make a recommendation), but I don't think it should remove choice when we know that that choice is sometimes needed.
Cheers,
David

I guess my point is that file is self describing. Not fully self describing, but it is. What would one do with a UGRID file of data without its domain description. It's properly useless right?  It doesn't pass the minimal requirement of being usable  in its own right.

Hi Bryan - I think "file" is a misleading. We've moved in to "dataset" territory. When external variables are in play, we have one dataset comprising two or three files. The dataset is self-describing, the constituent files aren't so much.

Hi Bryan - I think "file" is a misleading. We've moved in to "dataset" territory. When external variables are in play, we have one dataset comprising two or three files. The dataset is self-describing, the constituent files aren't so much.

Quite. So I am suggesting it be mandatory to give people enough information to turn our files into a dataset.  I am not suggesting it be mandatory that people use that information, but I think without it, we are putting a lot of requirements on data managers as opposed to users.

I don't see the conflict. In the optional case, if I was a data manager that liked the idea of the identifiers, than I simply wouldn't accept files without them (just like ESGF does not accept non-CMOR-ized CMIP files). Everyone's happy, right?

Dear all
I agree with David that CF aims to provide conventions which "give data writers freedom of expression with a well defined set of tools." That's related to principle 8 in sect 1.2, "Conventions are provided to allow data-producers to describe the data they wish to produce, rather than attempting to prescribe what data they should produce; consequently most CF conventions are optional." Hence my opinion (I think the same as David's) is still that it should be optional to provide an identifier in the parent file, and optional to require a match when using an external file, although they could be recommended by CF, and they could be required by a project that has its own stricter requirements.
In the case of the CMIP areacell[ao] variables and other external cell measures, we have managed without identifiers because there should be only one choice of these for any given AOGCM. Hence you can find the right external file by its name, in the directory for time-independent quantities. Providing the identifier in both files would be a useful extra check of the match.
CMIP is another case (distinct from my earlier example of manually creating an external file) where I think you don't want an opaque unique identifier. When the files are CMORised, they should all give the same identifier for areacella, for instance i.e. the one in the cell measures file that is supplied to ESG. The identifier will have to be hard-coded in the CMOR instructions for the dataset. Since you have to do this manually, I think it is more sensible and less error-prone to make it a meaningful identifier that the data producers are confident will be used only for this particular grid.
Best wishes
Jonathan

Hello.
Bryan gave us these user choices:

At reading the data time, there are two choices:
1. We have the domain description file which matches the unique identifier and are good to go, or
2. We have a domain description file which we believe to be correct, but the unique identifier doesn't match, we may have reason to trust that it is appropriate to use this, so we proceed with caution.

I think that these user choices are correct, but there is a third choice of:

We have a domain description file but the unique identifier doesn't match that from the parent file, so we don't want to use it.

I don't think we should force a writer to put a user in that position. The writer can choose to put a user who likes choice 3 in that position - perfectly fine - but there will be cases when they don't want to. A use case has been discussed here: the fact that there may sometimes be multiple identifiers in multiple valid external files, any of which might by acceptable for use. The writer should have the option of giving a user the flexibility of not being constrained by an arbitrary one of those identifiers.
There's no danger that optional identifiers will not get used by data creators who want to use them (who doesn't use at least one of standard_name and long_name, even though it's allowed to provide neither?), but there is a danger of mandatory identifiers having the unintended consequence of preventing the use of a dataset. I think that identifiers are great, that their use should be recommended by CF (so the checker will warn if none are provided in the parent file), but that it is not appropriate for them to be mandatory.
On the question of UUID/meaningful-string, I think that there are good arguments for types, so the identifier should be unrestricted (within the permitted character set).
Cheers,
David

Dear all,
This issue urgently needs a moderator!
Moreover, I suggest that the moderator at the earliest convenience convenes an offline group to tease out the essentials in the different viewpoints.
/Lars

Dear all,
This issue urgently needs a moderator!
Moreover, I suggest that the moderator at the earliest convenience convenes an offline group to tease out the essentials in the different viewpoints.
/Lars

HI Lars. David and I did discuss this offline this morning. Our suggestion is that we'll wait another day, then generate a summary of the (one?) key issue(s) of disagreement (we can agree that easily enough) and then I would suggest we simply vote on which direction we pursue in further fleshing out the proposal.
In advance of that summary,  I would say that there are two respectable positions on the table, neither are False in the sense that any of us would argue that others are (logically) Wrong.  I believe that the proponents of both sides believe their positions are correct, and  are unlikely to be further persuaded by finer detail of the arguments - so a consensus by mutual agreement seems unlikely.  I also believe that no one so far believes that their position represents something upon which they MUST WIN, so a vote would be a reasonable way of achieving a way forward.
If that's an acceptable way forward, then we can worry about how to vote next. But come what may, David and I attempt a summary of things in the next couple of days.

Meanwhile, I'll add another two more user cases for folks to mull over (ok, the second is a summary, but ...)

There is a model which generates a different domain filling curve for their cell descriptions for every different domain decomposition.  The group with that model currently consider that a bug, and will "fix" it, but it's not immediately obvious it's a silly thing to do - if you want to ensure efficient use of the overall UGRID decomposition in a heavily parallel environment (or if you are making heavy use of chunking to the point of chunking your domain, which might vary on application).  That means there is no "unique" correct order of cells for a given model and in that situation, they would be writing a domain description to accompany the data of each and every simulation - and of necessity, they will need such a mandatory identifier.  Now you might say well, yes,  but that's a choice, to which I'd say, yes, but this was a foreseeable situation, but one which one might ignore at first, and then later go "oh bugger".   (I am allowed to say "bugger", it is perfectly acceptable English in the Antipodes and not even a little bit offensive.)

We know that folks move files. They rename files. They download files from everywhere.  This is why we have strongly resisted breaking information up between files before (with the one obvious exception, which we have already discussed). They will make mistakes. If they have identifiers, such mistakes are recoverable.  The cost of requiring identifiers is trivial compared to the potential cost to the consumers. After all, we write all this metadata for consumers, not producers.  Why on earth would we not make it mandatory?

If we can't reach a consensus in this GitHub discussion, I think the right procedure would be the one we followed for (what became) units_metadata, which was proposed by David worked well. Namely, to invite anyone that would like to be involved to join an interactive discussion online by zoom or whatever, in order to formulate a recommendation to bring back here. Maybe the group will find a consensus, maybe not, but somehow it should decide what to recommend. At the time that group was formed, it was also made clear that we would expect the community to accept the group's recommendation, whatever it is (except for minor things that don't affect it substantially).

That'd certainly be fine by me, I had forgotten that we'd used that mechanism despite Lars actively suggesting it above. Sorry.  Do you think it's worth trying to summarise where things are now first? My sense is that we have a lot of information on the table now, and we can synthesise it now as input to such a discussion.

A summary would certainly be helpful for me.  Presumably it could provide some of the text that eventually made it into the "recommendation" resulting from the process, reducing overall effort down the road.

hello
regarding:

namely, to invite anyone who would like to be involved to join an interactive discussion online by zoom or whatever, in order to formulate a recommendation to bring back here.
(https://github.com/cf-convention/cf-conventions/issues/357#issuecomment-2149755018)

how may one suggest themself to be involved in this activity please?
many thanks

namely, to invite anyone who would like to be involved to join an interactive discussion online by zoom or whatever, in order to formulate a recommendation to bring back here.
how may one suggest themself to be involved in this activity please?

I plan to get a summary back here some time early next week, try and take the temperature of the immediate response, and then probably poll for "interested parties" on this ticket, following that, we'll likely doodle for a suitable time.  We may be in a hurry if we want to get folks before they disappear for summer.

thank you


Adding Metronome job queue functionality

command:   job queue, job queue startdeadline, job queue --json, job queue -q
dcos job queue
ID                         JOB RUN ID
startdeadline  /startdeadline/201801172321181BlLt

 dcos job queue --json
[
  {
    "jobId": "startdeadline",
    "runs": [
      {
        "runId": "/startdeadline/201801172321181BlLt"
      }
    ]
  }
]

rebased

run linux integration tests

run linux integration tests

let me double check master on this :(

sorry on this... the PR to fix master didn't land yet... I will follow up there.

run linux integration tests

@kensipe Should this PR be closed and recreated for https://github.com/dcos/dcos-core-cli ?

@kensipe : please re-open the PR against the core CLI

👍


fix(bug):  Fix form validation does not work in Kotlin.

Description

-Xjsr305=strict: This argument changes how the Kotlin compiler handles nullability annotations. The strict mode means that the compiler will strictly check nullability annotations and give a warning or error when it finds a problem.
-Xemit-jvm-type-annotations: This argument makes the Kotlin compiler emit JVM type annotations into the bytecode.

Fixes #2343
Type of change

[x] Bugfix
[ ] Feature

Checklist

[ ] I have read the contribution guide: https://vaadin.com/docs/latest/guide/contributing/overview/
[ ] I have added a description following the guideline.
[ ] The issue is created in the corresponding repository and I have referenced it.
[ ] I have added tests to ensure my change is effective and works as intended.
[ ] New and existing tests are passing locally with my change.
[ ] I have performed self-review and corrected misspellings.

Additional for Feature type of change

[ ] Enhancement / new feature was discussed in a corresponding GitHub issue and Acceptance Criteria were created.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I apologize for my previous misunderstanding of the Groovy programming language. I was not aware that Groovy allows direct assignment to lists without the need to call the addAll method. I have tested these changes locally and confirmed their correctness. Please review this PR again, thank you.


Installing forked version of typedoc-plugin-pages to satisfy the newer typedoc version

…r typedoc version plus adding removing some config for typedoc
Thank you for submitting this pull request :)
Fixes #2520
Short description
Changes for typedoc to smoothly migrate to the newest version of 0.20.0 and beyond.
The @sastan/typedoc-plugin-pages is a fork of the typedoc-plugin-pages which allows us to write our own markdown files inside of typedoc which was giving lot of errors due to breaking changes introduced in typedoc but the fork works with the newest version of typedoc.
Finally there are also some config changes to the typedoc.json file to migrate it to the new version.
Definition of Done

[ ] Steps to manually test the change have been documented
[ ] Acceptance criteria are met
[ ] Change has been manually tested by the reviewer (dApp)

Steps to manually test the change (dApp)

cd raiden-ts
yarn docs
npx serve ./docs
Docs should be available on  http://localhost:5000

@weilbith If you could have a look again.


Data for Electricity has 321 users not 370

Hi,
I would like to check if I see it correctly that in papers researcher refer to the data with 370 users and the data here have 321.
https://archive.ics.uci.edu/ml/datasets/ElectricityLoadDiagrams20112014
If so, do you think it is possible to update?
Thank you very much.
Luboš

The dataset in this repository comes from here. The original data has been cleaned up by removing all data for 2011 (due to some erroneous data), and has been converted to hourly consumptions.
If you want to use the original dataset, you can write a variant of the get_data-function from dataloader.jl. If you open one of the bson-files you can see that they contain a large matrix inp_raw with the raw input data - you just have to replace that with the data from the full dataset, and then proceed by creating the output features as in out_ft and the output labels similar to what is done with out_lb.

Thanks a lot. I apologise for an invalid issue.

No worries. Filing an issue is the easiest way to get in touch with me, so that's perfectly fine.


add pile calib, rename quant_block_list to to_quant_block_names

could fp layer also support fuzzy matching

fp_layers = args.fp_layers.split(",")
if bool(fp_layers):
    for n, m in model.named_modules():
        if isinstance(m, torch.nn.Linear) or isinstance(m, transformers.modeling_utils.Conv1D):
            name = n.split('.')[-1]
            if n in fp_layers or name in fp_layers:
                layer_config[n] = {"bits": 16}
                logger.info(
                    f"{n} will not be quantized.")

why coding like this , name = n.split('.')[-1]?  how to  exclude a exact layer


Fetch API cannot load ...

Receiving these errors in console

OPTIONS https://api.twitter.com/1.1/statuses/user_timeline.json?screen_name=richappdev 400 ()

Fetch API cannot load https://api.twitter.com/1.1/statuses/user_timeline.json?screen_name=richappdev. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access. The response had HTTP status code 400. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Trying to use this twitter api to work in my web app, I understand that I am trying to make a request somewhere different than my location (local host) and need to change a header but not sure where and how to do that. Do I need to change something in the twitter api lib/twitter.js ?
Thanks in advance for the help

any update?

Hi @rdpompeo and @iamsaksham , I just tried and it can be solved by requesting twitter API from server instead of client/browser. Reason is here: #189


Remove custom k8s-app label in favor of standard k8s labels for Alertmanager

lgtm
@lilic can you have a look as well?


Add missing links for keep-a-changelog-ish diffs

Looks like they stopped after v6.5.0

Coverage increased (+0.02%) to 85.298% when pulling 888eb5f4fef08fc0e63c7e9ab2ed86761f1358da on op-ct:patch-1 into<PHONE_NUMBER>de8287b6a0f4870de1e48115b2ab5d on rodjek:master.


Add company website for JobPosts

This PR adds the Website for JobPosts. Earlier only the jobs_link was getting returned from the API.

@SheldonCheng verify if the response is correct.

This will fix #167


Make screenshot function return an Image

Returning an image rather than always opening a new window slightly expands the utility of embedding v86---we may want to take a screenshot and use just its data without asking the user to download it.

Cheers!


Update documentation for ansible usage

Currently we have two parallel ways of deploying OpenWhisk: ant and ansible.
Once we flip the switch and drop ant, we should have some documentation ready for the users and devs.
Doc should include:

How ansible works
How we apply ansible for deployment
Playbook structure (environments, roles, modes, conventions on variables: a.b vs. a_b)
How a user can adapt existing or create new environments

User guide should be updated to make the new way of deploying like:
ansible-playbook -i env whisk.yml -e mode=initdb
gradle distDocker
ansible-playbook -i env whisk.yml

I've subscribed since we have several blogs (besides READMEs) that we may need to update that reference ant...

I have reviewed the pull requests and tried it myself. I find the ansible commands much more verbose and expect we will want to sugar these to get back to the simplicity of ant clean build deploy.


Yes this needs to be backported (please exclude ChainerMN one).


Option selectors are case sensitive

I think the option selectors should be case insensitive, or the menu should have an option do disable the sensitivity.

Resolved in v0.1.0


associative collection parsing

Hi I have JSON like this
{
"response": {
"groups": {
"123456": {
"id": 1,
"name": "group 1",
"type": "group"
},
"67890": {
"id": 2,
"name": "group 2",
"type": "group"
}
    }
}

}
How I can parse it with alamofire properly? Please help

Create a Group class that conforms to Mappable. Then you can map the groups as follows:
class Response: Mappable {
    var groups: [String: Group]?
    // init code

    func mapping(map: Map){
        groups <- map["groups"]
    }
}

And what method to send all to mapping from alamofire? In your examples its not so clear and old alamofire methods

From my samples:
Alamofire.request(.GET, URL).responseObject { (response: Response<Response, NSError>) in

}

responseObject doesn't exist in Alamofire

ResponseObject is the function that this extension provides...
You have to import AlamofireObjectMapper at the beginning of your file to have access to the functionality this extension provides.


Volume 100%

When trying to set the volume to 100% through home assistant it doesn’t work. If I set the volume to max through the HTD app, the HTD plugin in HA shows 0

Are you still experiencing this problem? I am unable to reproduce this and I have not had any other reports of this.

Yes, I can still reproduce it. When the volume is set to 100% in HA, the HTD app shows its set to 59 (max is 60). If I try and change the volume to 60 in HTD, I'm then unable to adjust the volume in HA.

yea i can reproduce this actually

yea i can reproduce this actually

Great, let me know if you want me to test anything

Hey @S10XtremeNLow -
Thanks for being patient. I completely rewrote the python client. I think this should be much better now. The way that this device switches volume though is really sucky. It can only tick 1 volume db at a time. So it takes a few seconds to get to the new desired volume. If there's a volume change in progress on a zone, any volume changes will be ignored until it's done with the initial request.
If you can give it a go and give me your first impressions that would be really appreciated. If you installed this via HACS, you should be able to choose a new preview version of v1.2.0-BETA.1.
Please give it a shot and let me know how that goes.
Thanks.

Hey @S10XtremeNLow -
Thanks for being patient. I completely rewrote the python client. I think this should be much better now. The way that this device switches volume though is really sucky. It can only tick 1 volume db at a time. So it takes a few seconds to get to the new desired volume. If there's a volume change in progress on a zone, any volume changes will be ignored until it's done with the initial request.
If you can give it a go and give me your first impressions that would be really appreciated. If you installed this via HACS, you should be able to choose a new preview version of v1.2.0-BETA.1.
Please give it a shot and let me know how that goes.
Thanks.

What a Father’s Day gift! Thanks, I’ll let you know if I see any issues.

Hey @S10XtremeNLow -
Thanks for being patient. I completely rewrote the python client. I think this should be much better now. The way that this device switches volume though is really sucky. It can only tick 1 volume db at a time. So it takes a few seconds to get to the new desired volume. If there's a volume change in progress on a zone, any volume changes will be ignored until it's done with the initial request.
If you can give it a go and give me your first impressions that would be really appreciated. If you installed this via HACS, you should be able to choose a new preview version of v1.2.0-BETA.1.
Please give it a shot and let me know how that goes.
Thanks.

Looks like the release hasn’t been published to GitHub. I get a 404 when trying to install on HACS. 404 on this URL. https://github.com/hikirsch/htd_mc-home-assistant/releases/download/v1.2.0-BETA.1/htd_mc.zip
Want me to install manually?

Oh, sorry, I didn't upload the files to the release, you can download the files from the branch  directly or use HACS and pick this as a new pre-release. I can upload the files in the release later.

Oh, sorry, I didn't upload the files to the release, you can download the files from the branch directly or use HACS and pick this as a new pre-release. I can upload the files in the release later.

I’m choosing the branch from HACS. See attached photo

ok can you try again? sorry about that.

Installed this time but getting “Setup failed for 'htd_mc': Integration not found. “
looking at the folder directory, looks like htd_mc is inside a htd_mc folder along with a MACOSX directory

not my day.... can you try again?

Any requirements change for configuration? Getting this error now: Component error: htd_mc - No module named 'htd_mc_client'

definitely not my day, can you try again? there's now a beta.2

It sets up now. Looks like it can’t get current power state of a zone. Had a zone on and it didn’t show on. I can turn on a zone but it doesn’t show the new state so can’t turn off the zone.

ok at least progress, yes this I'm aware of. does it eventually stabilize? are you able to set the volume properly?

Kind of. I had on state (they were all on in HA) but none were actually turned on. The volume does go to max and minimum now. It does seem like it locks up when changing the volume. For example if I’m at 5 and go to 80 on accident and try to change it to 40, it doesn’t respond.
Getting closer!

can i ask you to reach out to me on Discord?

Sure, my name is same as on here
Brandon
On Jun 17, 2024 at 9:32 PM -0400, Adam S. Kirschner @.***>, wrote:

can i ask you to reach out to me on Discord?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

hey @S10XtremeNLow thanks for your help with this! i released v1.2.0 with the new options and as a final.
going to close this. please report further issues here!


Examples: Entity resolver

Adding entity resolver example. Also quickly sketched html maker to render graph networks.

wow this one is very complex mind adding a bit of a readme?

Sure, python is bit more straightforward to make graphs 👀

im dumb:
https://github.com/jxnl/instructor-js/actions/runs/7403430039/job/20143213010
found an error


TEIIDTOOLS-64: Moves the preferences page into dataservices plugin

Constructs a dataservice page to display the preferences complete with
their own button in the top-right next to the help button.

.../config.js

Removes the html for the preferences menu item in the hawtio user menu

dataservice-main

Since each pref page supplies its own help, both the preference and help
buttons are hidden

dataservicePageController

Tracks the previous page clicked on prior to selecting a page since this
needs to be restored on clicking return from the preferences page

dsPrefController

Logic taken from the hawtio preference page

git-preferences.html

teiid-preferences.html

Corrected recursion error with the help control since the preference page
is now a page from the dsPageService

gitCredentialsControl.html

teiid-preferences.html

Removes save/update buttons and replaces it with ng-blur (on-focus-leave)
event handling for each widget, ie. save-as-type

pageHelpControl.js

Removes reference to testing website

See screenshots:

http://phantomjinx.co.uk/stuff/prefs-1.png
http://phantomjinx.co.uk/stuff/prefs-2.png

screen cap looks good and solves the help icon problem.
Does the pref. category list box width scale with resized window or is it fixed width?  if fixed.. then can you narrow it up a bit.

"Does the pref. category list box width scale with resized window or is it fixed width? if fixed.. then can you narrow it up a bit."
Scales with width of window.

What do you think about moving preferences over to the main navigation tabs along with Data Services, Data Sources, and Dashboard? Then when you click Preferences you would get menu items for Git Repository Configurations and Teiid Settings. The Return button just seems a bit different than what the user is used too. This would make the look of the preference pages consistent with the other pages.

@elvisisking
I don't see the preferences as a full page in that sense. It is more akin to the help (in fact I started with preferences being displayed via a slide-in). In the end, they just are not important enough to be part of the use-cases launched from the navigation bar.
In addition, and separately, the return button can be edited to a UI more suitable but it does fulfill the specific purpose of returning the user back to the page they left rather than back to the 'home' / summary page. For example, having already clicked on the export / import pages I remember I need to modify the git preferences; at that point I wish to return to the same export / import page.

Cloudforms uses Patternfly and Vertical navigation... and they use a "Settings" tab, which someone suggested awhile back as an alternative
I could also foresee adding various options to set default behavior for some of our options... like "Set Filter Condition default to TRUE/FALSE" in the configure data source panel.


Uploading a CSS file appends a semicolon to content type

Storage Explorer Version: 1.15.1
Build Number: 20200902.9
Platform/OS: Windows 10 Pro
Architecture: x64
Regression From:  Not Tested
Bug Description
Uploading a CSS file appends a semicolon to the content type (resulting in text/css;). The file is served normally and that does not create any apparent issue. However, when served through Azure's CDN with compression enabled, the file is not compressed because the returned content-type response header is text/css; which cannot be in the list of formats to compress.
This happens only with CSS. It does not happen with application/javascript or image/jpeg.
The workaround is to change the content type after uploading so the bug is minor but it took a week of investigation so this may save time for someone else.
Steps to Reproduce

Select a blob container.
Upload a CSS file to any location.
After the upload is complete, check the blob's content type.

Expected Experience
Content type should be text/css.
Actual Experience
Content type is text/css;.

@MarcAnnous when you say "the returned content-type response header is text/css; which cannot be in the list of formats to compress", is the list of compressable content-types something that Azure CDN defines? And if so, do you have a link to any Azure CDN docs which list out all compresssable types?

There's a pre-defined list: https://docs.microsoft.com/en-us/azure/cdn/cdn-improve-performance
This list cannot be modified currently on Azure CDN Standard by Microsoft.
On Azure CDN by Verizon and Akamai the list can be changed but it only accepts valid mime types without additional characters.
Screenshot:

AzCopy is going to ship a fix for this bug in their 10.6.1 release.

We'll be shipping a new version of AzCopy in our 1.16.0 release, and that version will have the fix as well.


Fix OOM on MacOS when using xcode 12.5

Usage of VM_FLAGS_SUPERPAGE_SIZE_ANY when doing allocations causes
ponyc to OOM if it is built with xcode 12.5.
Fixes #3789

@ergl this PR doesn't include updating to using xcode 12.5 in CI so we can verify this change is "safe" with an earlier xcode version. Once this is merged, I have two other macOS related PRs coming including updating our CI to use xcode 12.5.

@ergl this is a pretty straightforward change. for a review, i'm most interested in, "are the release notes clear?"

@SeanTAllen Yes, I think they're fine


"Encrypting Store" wiki page : command to create the master key store

Hi Axel,
This is not an issue but an update of your wiki :
In "Encrypting Store" wiki page, command to create the master key store for your configuration example is :
JAVA_HOME/bin/keytool -genkey -alias encrypt -keyalg RSA -keypass encrypt -storepass encrypt -keystore [ALFRESCO_INSTALL_DIR]/shared/classes/classes/keystore.jks
Regards,
Emmanuel

Now documented in the relevant store documentation (will no longer use wiki for documentation, but use Markdown documents in source tree, which are easier to keep track off for different versions of the addon).


Cannot import tiktoken into flask app - PyO3 modules may only be initialized once per interpreter process

I can load tiktoken locally with flask but once I try to use it on PythonAnywhere in production it errors with.
Both are using Python 3.10
Traceback (most recent call last):
  File "/home/simonpalmer/ideally/flask_api.py", line 11, in <module>
    import tiktoken
  File "/home/simonpalmer/.local/lib/python3.10/site-packages/tiktoken/__init__.py", line 1, in <module>
    from .core import Encoding as Encoding
  File "/home/simonpalmer/.local/lib/python3.10/site-packages/tiktoken/core.py", line 9, in <module>
    from tiktoken import _tiktoken
ImportError: PyO3 modules may only be initialized once per interpreter process

Which version of tiktoken has migrated to Py03?

This is the same issue you opened here: https://github.com/openai/tiktoken/issues/126 Please discuss there. In particular, create a reproducer.


Change Method keyboard shortcut not working on mac

Expected Behavior

Pressing shift+command+L should open the HTTP Method dropdown list to choose from.
Pressing command+L should move cursor to url bar.

Actual Behavior

Pressing shift+command+L does nothing.
Pressing command+L show focus on url bar but cursor still remains on body editor.

Reproduction Steps
No response
Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
No keybinding overridden. No plugins installed.
Insomnia Version
v2023.1.0
What operating system are you using?
macOS
Operating System Version
Ventura 13.4 Beta (22F5027f)
Installation method
download from insomnia.rest
Last Known Working Insomnia version
No response

👀 Anyone listening? It kills the productivity. Every time i need to make a change in query param or url, I need to reach out to mouse because Keyboard shortcut (cmd+L) only highlight the address bar, does not move cursor there. In earlier versions it used to work fine.

This should have been fixed.

Except the command+L focus problem


how do I stop OneSignal from resetting the badge count automatically?

I am trying to maintain the badge count on the app icon until the user visits a specific section in my app. This section is in the TabBar and I want to bind the badge in the TabBar to the badge count. This is impossible if OneSignal clears the badge count automatically each time we receive notifications.

Try this, on your Android Manifest file:
<meta-data android:name="com.onesignal.BadgeCount" android:value="DISABLE" />
Not sure on iOS, though.

sorry this question was for iOS and I found the answer https://github.com/OneSignal/OneSignal-iOS-SDK/issues/11

Thanks @masterkrang


fix(disk/lsblk): support different lsblk version

I try to fix the problem one in issue

Please review https://github.com/leptonai/gpud/pull/278 -- I cherry-picked your patch.

Let me close in favor of https://github.com/leptonai/gpud/pull/278.
Thanks for your contribution!
We will include https://github.com/leptonai/gpud/pull/278 in the next release.


macOS Installation problem

Hello there,
Trying to install trashy on my MacBook (Intel processor) but I get the below error:
error[E0433]: failed to resolve: could not find `os_limited` in `trash`
  --> ~/.local/share/cargo/registry/src/github.com-1ecc6299db9ec823/trashy-1.0.2/src/app/command/empty.rs:52:12
   |
52 |     trash::os_limited::purge_all(items.items())?;
   |            ^^^^^^^^^^ could not find `os_limited` in `trash`

error[E0433]: failed to resolve: could not find `os_limited` in `trash`
  --> ~.local/share/cargo/registry/src/github.com-1ecc6299db9ec823/trashy-1.0.2/src/app/command/list.rs:64:28
   |
64 |     let mut items = trash::os_limited::list()?;
   |                            ^^^^^^^^^^ could not find `os_limited` in `trash`

error[E0433]: failed to resolve: could not find `os_limited` in `trash`
  --> ~/.local/share/cargo/registry/src/github.com-1ecc6299db9ec823/trashy-1.0.2/src/app/command/list.rs:90:36
   |
90 |             let mut items = trash::os_limited::list()?;
   |                                    ^^^^^^^^^^ could not find `os_limited` in `trash`

error[E0433]: failed to resolve: could not find `os_limited` in `trash`
  --> ~/.local/share/cargo/registry/src/github.com-1ecc6299db9ec823/trashy-1.0.2/src/app/command/restore.rs:49:12
   |
49 |     trash::os_limited::restore_all(items.items())?;
   |            ^^^^^^^^^^ could not find `os_limited` in `trash`

For more information about this error, try `rustc --explain E0433`.
error: could not compile `trashy` due to 4 previous errors
error: failed to compile `trashy v1.0.2`, intermediate artifacts can be found at `/var/folders/3c/4h7rrmnd2s1cjhqysqk345lm0000gp/T/cargo-installEiaubN`

OK it seems there is an issue with MacOS.
I am currently using it with another computer with Arch installation and I really like it.
Especially the tables and colours that come with it ;)


Feature request: Set camera sensor values

My sensor in T-Camera Mini need some additional config like vflip may be hmirror.
My idea is to add a new function
def set( vflip = None, hmirror = None, brightness = None, saturation = None,  framesize = None ):
Reference could be:
https://github.com/Xinyuan-LilyGO/TTGO_Camera_Mini/blob/master/TTGO_Camera_Mini.ino Line 151
But my skills to write a C extensions for micropython are limited to read (C and python) code.

Provided a pull request #4 for this also.

Thanks! I've just merged the PR and updated the MP version.


Kill classnames dependency~

I think this is a dependency that's pretty easy to kill

Yeah, agreed. I'd been considering doing this.

I hadn't looked at it, but you're right, it's pretty tiny~ I'll close this PR.


Adding npm registry credentials through pipeline variables causes `concat': no implicit conversion of String into Array (TypeError)

I have a issue configuring the npm credentials though Azure Step Extension in the variables section of the pipeline.
Adding DEPENDABOT_EXTRA_CREDENTIALS with the example from the docs (a single array with one object)  causes
./update-script.rb:114:in `concat': no implicit conversion of String into Array (TypeError)
	from ./update-script.rb:114:in `<main>'

Hi @MassivDash please share what inputs you are providing to better understand why this may be the case.


Add --skip-db option to dump command

Attempts to resolve #28720.

Note that I am not a Gitea administrator so I don't normally use the gitea CLI. Just saw this issue and wanted an opportunity to understand how this subcommand works and see if I can add this feature :^)
I tested both with --skip-db and without and it appears to not add any database-specific files to the generated archive i.e. I don't see a gitea-db.sql or gitea.db file:
$ TAGS="bindata sqlite sqlite_unlock_notify" make backend
Running go generate...
bindata for migration already up-to-date
bindata for options already up-to-date
bindata for public already up-to-date
bindata for templates already up-to-date
$ ./gitea dump --skip-db
2024/04/20 01:16:11 ...s/setting/session.go:77:loadSessionFrom() [I] Session Service Enabled
2024/04/20 01:16:11 ...s/storage/storage.go:176:initAttachments() [I] Initialising Attachment storage with type: local
2024/04/20 01:16:11 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /workspaces/gitea/data/attachments
2024/04/20 01:16:11 ...s/storage/storage.go:166:initAvatars() [I] Initialising Avatar storage with type: local
2024/04/20 01:16:11 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /workspaces/gitea/data/avatars
2024/04/20 01:16:11 ...s/storage/storage.go:192:initRepoAvatars() [I] Initialising Repository Avatar storage with type: local
2024/04/20 01:16:11 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /workspaces/gitea/data/repo-avatars
2024/04/20 01:16:11 ...s/storage/storage.go:186:initLFS() [I] Initialising LFS storage with type: local
2024/04/20 01:16:11 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /workspaces/gitea/data/lfs
2024/04/20 01:16:11 ...s/storage/storage.go:198:initRepoArchives() [I] Initialising Repository Archive storage with type: local
2024/04/20 01:16:11 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /workspaces/gitea/data/repo-archive
2024/04/20 01:16:11 ...s/storage/storage.go:208:initPackages() [I] Initialising Packages storage with type: local
2024/04/20 01:16:11 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /workspaces/gitea/data/packages
2024/04/20 01:16:11 ...s/storage/storage.go:219:initActions() [I] Initialising Actions storage with type: local
2024/04/20 01:16:11 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /workspaces/gitea/data/actions_log
2024/04/20 01:16:11 ...s/storage/storage.go:223:initActions() [I] Initialising ActionsArtifacts storage with type: local
2024/04/20 01:16:11 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /workspaces/gitea/data/actions_artifacts
2024/04/20 01:16:11 cmd/dump.go:172:runDump() [I] Dumping local repositories... /workspaces/gitea/data/gitea-repositories
2024/04/20 01:16:11 cmd/dump.go:195:runDump() [I] Skipping database
2024/04/20 01:16:11 cmd/dump.go:229:runDump() [I] Adding custom configuration file from /workspaces/gitea/custom/conf/app.ini
2024/04/20 01:16:11 cmd/dump.go:256:runDump() [I] Packing data directory.../workspaces/gitea/data
2024/04/20 01:16:11 cmd/dump.go:335:runDump() [I] Finish dumping in file /workspaces/gitea/gitea-dump-1713575771.zip
$ unzip /workspaces/gitea/gitea-dump-1713575771.zip -d example
Archive:  /workspaces/gitea/gitea-dump-1713575771.zip
. . .
$ ls example/
app.ini  custom  data  repos
$ ls example/data/
actions_artifacts  actions_log  avatars  home  indexers  jwt  queues  repo-archive  repo-avatars  tmp

An idea unrelated to this PR I had while working on this. A --skip option could be added where uers can include what they want to skip as a StringSliceFlag i.e. --skip db, repository, custom-dir. Though we would need to document them all in a single option; not sure if that may be a problem.


feat: Math support

Close #20

I will review this in February as part of https://github.com/Witiko/markdown/issues/216 if that's OK.

Just rebased and conflicts fixed, for now.
@Witiko

I will review this in February as part of https://github.com/Witiko/markdown/issues/216 if that's OK.

No problem at all, you are welcome.
I might merge it here "as-is" in this "vendored" copy of the lunamark reader later this month, so as to move forward with my 1.1 planned release of the SILE-Markdown tooling and to tickle SILE a bit on its Math support, but there's no urge as far as lunamark is concerned (that the advantage of using a vendored copy at this early point... with all the drawbacks too, though!)


Fixed #30353 -- Fixed recursion message assertion error

The message is correct, the test just needs to be adjusted to be on sys.getrecursionlimit().
https://github.com/django/django/pull/11173

Closing due to the ticket.


3.21.1 English & German

Complete English
German till 60860 will do rest later
@Auhrus you want to check the German part?
(Pull delayed until the release of 3.21.1)

Fixed incorrect entries and added some translations in the process,
Also fixed some existing translations and we may need to take a look at the tutorial because it seems like they changed the texts a lot.
Will continue to translate the last new entries.

If all reviews pass and 3.21.1 comes out. Ready to push.

Sorry for the late response. Have you already gone through all the new entries @ROBdk97?

Sorry for the late response. Have you already gone through all the new entries @ROBdk97?

Yeah, should be done. Would be nice if you check if I missed anything ^^

Would wait until the patch goes live.

Top that's exactly what I meant then it goes 👍

@electronicfreak this is for 3.21.1 not for 3.20. Why did you push it already?


Changes file cannot be overwritten

The example script for Continuously updating a database was fixed to delete the newchange.osc.gz file, if exists, before executing pyosmium-get-changes.
Otherwise, at the second iteration of the script  pyosmium-get-changes would issue an error:
Traceback (most recent call last):
  File "/usr/bin/pyosmium-get-changes", line 243, in <module>
    exit(main(sys.argv[1:]))
  File "/usr/bin/pyosmium-get-changes", line 224, in main
    outhandler = WriteHandler(options.outfile)
RuntimeError: Open failed for 'newchange.osc.gz': File exists

Indeed. Thanks!


ASN1_STRING_to_UTF8 could not convert NumericString

tag2nbyte have -1 at 18th position, but underlying ASN1_mbstring_copy supports NumericString.
tag2nbyte also used in do_print_ex which will not be broken by setting 1 at 18th position of tag2nbyte.

Fixed by d6079a87db5. Closing.


Feature Request: Add ability to change/add descriptions to Collections and Fields

It would be nice to have the ability to add a separate description field to collections and fields or to make the description that they already have editable. Something like "Number value." explains what type the field is, but I don't know whether there is a specific range for the value, if it has to be unique, if there is a specific regex for it etc.
That can also help if a field (or the collection) needs some description or explanation on how it should be used.
Would this be possible?

In the future we may improve the auto generated hint texts but custom description field for now is not planned because it may ended up cluttering the UI making the schema magement experience too overwhelming (the same reason why we also don't have a dedicated field label input).


Update pilot crash message to link to WIP PR on GitHub

As it will take a little longer to migrate everything from pilot, we now show a nice error message that links to the GitHub PR, with more information about the current status

          1 Warning

:warning:
Pull Request is Work in Progress

  Generated by :no_entry_sign: Danger

Nope it's not @fastlane-bot-helper 👍

Merging for @KrauseFx so that we can get a release out this morning.


SNAPSHOT of seaweeds-client 1.6.1 is missed in sonatype repository

In this repository,
https://oss.sonatype.org/content/repositories/snapshots, there is only seaweedfs-client 1.0.1-SNAPSHOT, whereas I want to use the latest 1.6.1-SNAPSHOT version, which is missing, please upload the latest snapshot version of seaweeds-client. And is there giteer conversation room for this project ?

https://mvnrepository.com/artifact/com.github.chrislusf/seaweedfs-client/1.6.1


Participate in FigureFriday and create a Vizro app (for multiple participants)

Good choice! 👋
You will learn 📚:

Navigating through technical documentation
Working with Plotly charts and customizing them via post update calls
Utilizing PyCafe for development and building your own portfolio
Creating your Vizro app from scratch

Instructions

Explore Plotly's FigureFriday and choose any week you would like to participate in. Reviewing previous weeks can inspire your potential submissions. Your task is to take the relevant data set and enhance the existing Plotly visualization. This could involve creating a new chart or improving the current chart code.

Create an account on pyCafe if not already done: https://py.cafe/ Fork the Vizro project template to your account. This will allow you to customize the Vizro app.

Get familiar with Vizro's app configuration and add some changes. Refer to Vizro's documentation  to understand how to configure the models. Here are some ideas for modifications:

[ ] Add a Graph to your Page and insert a Plotly chart
[ ] Add a Graph to your Page and insert a custom Plotly chart
[ ] Add your Page to the Dashboard
[ ] Add a title to your Dashboard
[ ] Add a logo to your Dashboard e.g. take the vizro logo here:
[ ] Add controls to your Dashboard (Filter or Parameter)
[ ] Add a second Page with a AgGrid to your Dashboard
[ ] Experiment with the Navigation e.g. create a NavBar
[ ] (Optional) Upload your app on py.Cafe and submit your app to the Figure Friday challenge

Useful resources:

Vizro documentation: https://vizro.readthedocs.io/en/latest/pages/user-guides/components/
Existing Figure Friday submissions using Vizro: https://py.cafe/huong-li-nguyen
First tutorial on dashboards: https://vizro.readthedocs.io/en/stable/pages/tutorials/explore-components/
Plotly documentation: https://plotly.com/python/plotly-express/
Plotly layout: https://plotly.com/python/reference/layout/

Hi @huong-li-nguyen I'm interested to work on this and create a Vizro dashboard from scratch and learn. Thank you!

Hi! I would love to work on this. My github username is sylviebartusek.

Looking forward to creating a dashboard for the FigureFriday challenge!

Hi , I would like to work on this and learn.

Hi Li, Looking forward to work on PyCafe and Vizro. :)

Hi, would love to work on this!

Hi, I would love to work on this

Hi, I would I like to work in this.

Hey all - so happy you guys want to do this one! Feel free to tackle this :)

If some others decide to do this later, anyone can take this ticket on. It's not limited to a number of participants as everyone would independently work on your pyCafe project :) Please add your pyCafe project links here, so we can eventually add it to our docs and give you some credits 👍

Hi, I would like to work on this too :)

Hi @huong-li-nguyen I'm interested to work on this and create a Vizro dashboard from scratch and learn. Thank you!

My Py.Cafe link for the APP: https://py.cafe/app/fatemeh.taer74/vizro-iris-explorer

HI, I am working on this: https://py.cafe/mut8188/vizro-visualization-demo

Hi, this is my code link
and the dashboard link

Hello everyone,
please let me know if you want me to add your example to our docs here: https://vizro--797.org.readthedocs.build/en/797/pages/examples/your-examples/#examples-on-github-or-pycafe
For this please:

Add a link to your pyCafe dashboard as comment here :)

@Mahsatr - the link unfortunately didn't seem to work - could you double-check?
@ManaliTanna - could you check if you pushed your changes? When I click on the link it seems to show our default vizro example :)
@KhushaliP - beautiful example! I've added it to our docs and linked to your Github profile 🚀

Hi @huong-li-nguyen - here is the link to my Py.Cafe dashboard: Dashboard Link
And I believe this should be the link to my code: Code Link https://py.cafe/fatemeh.taer74/Figure Friday 2024 - week 40

Hello @Mahsatr - this is a great Dash app, which I think you should definitely submit to the FigureFriday thread for that week's challenge! :) 🚀
To be added to our documentation unfortunately, you would have to use Vizro to build the Dash app though. Vizro in the end returns a Dash app, but automatically styles the app (see some of the documentation links in this ticket).

Hi @huong-li-nguyen - Thank you! I will definitely submit it to the FigureFriday Week 40 thread. :)
Regarding the documentation, I would love to write it up and experiment with Vizro too to be added to the documentation if that's something that could be done.

Hey @Mahsatr , what you could do is convert your Dash app to a Vizro app with the help of our documentation :)
It should be fairly straightforward, as you already have all the code. Afterwards we can always add your example to our documentation, there is no deadline :)