covalent
covalent copied to clipboard
AgnostiqHQ
Number of electrons & completed electrons should only reflect only 'executable' electrons
Description
The columns electron_num and completed_electron_num in the lattices table should only include the count for actual executable electrons and not include other electron types like parameters.
Details
- Currently even non executable electron types are considered while populating these columns Eg
parametertype electrons. Note the 19/19 besides 'Completed' in the image below.
- It is proposed to include only electrons that are executable since these two columns are shown to the end use in tandem with the graph as shown above.
- The DB schema proposes a list of possible electon types -
function,sublattice,parameter,electron_list,electron_dict,attribute,generated,subscripted,arg. The understanding is that only thefunctiontype should be considered since the end user is looking for that count.
@mshkanth , I would say the list of possible "types" of electron are listed here (and functional electron, which is the main normal electron that is not listed here). Following this I would say we need both sublattice/functional electron for the status.
This also reminds me, lets discuss with Soc on potentially differentiating the various forms of electrons here (Plus we need collapse in the minimap for the "types" of electrons above as well.)
@mshkanth , I would say the list of possible "types" of electron are listed here (and functional electron, which is the main normal electron that is not listed here). Following this I would say we need both sublattice/functional electron for the status.
This also reminds me, lets discuss with Soc on potentially differentiating the various forms of electrons here (Plus we need collapse in the minimap for the "types" of electrons above as well.)
@santoshkumarradha - There is already a 'parameter' hide/show toggle today. We can extend it to different things potentially. Is the tweak in total/completed electron, something we can expect for v11? Techncially it doesn't impact us at all, since we show this data from the DB directly to the GUI. However, the user might wrongly infer data shown on the screen as a result of this.
@mshkanth , I would say the list of possible "types" of electron are listed here (and functional electron, which is the main normal electron that is not listed here). Following this I would say we need both sublattice/functional electron for the status.
This also reminds me, lets discuss with Soc on potentially differentiating the various forms of electrons here (Plus we need collapse in the minimap for the "types" of electrons above as well.)
Hey @santoshkumarradha and @mshkanth - Just FYI the logic for getting electron types is right here. Normal electron is designated as a "function".
Hi @cjao - There were a few pending tweaks/requests we had based on v9 & v10 schema. Can you clarify if this issue is already covered in your v11 implementation? Else request @FyzHsn to share some timeline of when this might be incorporated.
Hi @mshkanth, V11 doesn't yet differentiate between functional and non-functional electrons in its electron count. Actually, while parameter electrons require no processing, the other electron types, indicated by electron_dict_prefix or electron_list_prefix do involve a small amount of computation which could potentially fail.
@mshkanth , we can go ahead with the current implementation and consider all these electrons are same. Lets have it as backlog to make this change both from DB side as well as front end side.
@mshkanth can you clarify the request?
The request was to maintain only count of functional electrons in lattices.electron_num and lattices.total_electron_num. These fields were introduced to primarily server the UI and might make more sense to the user if the above tweak was done.
@mshkanth can you clarify the request?
The request was to maintain only count of functional electrons in
lattices.electron_numandlattices.total_electron_num. These fields were introduced to primarily server the UI and might make more sense to the user if the above tweak was done.
What about sublattices? They're not categorized as functional electrons but rather sublattices
@mshkanth can you clarify the request?
The request was to maintain only count of functional electrons in
lattices.electron_numandlattices.total_electron_num. These fields were introduced to primarily server the UI and might make more sense to the user if the above tweak was done.What about sublattices? They're not categorized as functional electrons but rather sublattices
Would request @santoshkumarradha to clarify. Whatever makes sense to a user on the GUI for a workflow with multiple sub-lattices, that count needs to be recorded in the DB.