We have 3 types of design patterns, create, structural and behavioral design patterns. In each type contains few of the patterns, 23 different patterns in total.
I read you paper , you work in mathematic chemistry. I think what you characteristic the molecule with graph, but if use pattern syntactic with concept of G=(NT,NNT,S,P) , you will to determinate structural similarity y get you end result.
Design Patterns came into existence because the problems these patterns solves are available in numerous projects. in other words, design patterns solves a specific issue that occurs often while designing a software. hence the name "Design Patterns". its something like: if u want to make a bridge which cannot have pillars in between then you can adopt a "Arch Design" or a "Hang by wire design".
As of identical pattern, its very rarely used and hence one may not find in the established 23 patterns. Sometime these design pattern may not even apply on certain programming framework.
In MS.NET framework context for a given issue, if 2 or more design patterns fits to be useable for a given issue then we call these eligible patterns to be identical. I am not sure if the identical pattern that you are referring is in the same context.
Please let us know some more details about your question.
If you mean Design Patterns in Software Engineering, the idea comes from one the most influential book in computer science, ever, by GoF (Gang of Four: E. Gamma, R. Helm, R. Johnson, J. Vlissides): "Design Patterns Elements of Reusable Object-Oriented Software" (1995). In turn, they admitted they took the idea from Architecture, and specifically, from the book by Christopher Alexander "The Timeless Way of Building" (1977 if I remember well). The idea of Christopher Alexander was finding "timeless way of building" or design patterns in architectures addressing a recurring design problem that arises in specific design situations and presents a solution to it ..
If you write code, before the code you should address the architecture (system architecture, application architecture, functional architecture, UI architecture, etc...) and here patterns comes ... asking how to identify a design pattern is like asking how to "identify" a person: very easy and natural to do but very difficult to specify algorithmically. Moreover, design patterns are not just about code. You can implement design pattern in a particular hardware architecture/configuration. For instance a node of your architecture can be a "proxy" ... ops, the proxy is a structural design pattern whose intent is to provide a surrogate or placeholder for another object to control access to it ...
By looking into the source code and finding which design pattern is used can only be done if we know all the 23 patterns thoroughly. If u want to use a tool then the nearest one will be an "object designer" . you can find a object designer in an IDE (like eclipse/ visual studio ) . By dropping all the class files (source code) into the designer, it will automatically draw the class diagrams with all relationships. by comparing this design with the existing class diagrams of the design patterns we can get a hint on what patterns are used.
There are some source code query and analysis tool to detect such patterns in a source base. E.g., the CrocoPat Tool, with which you can specify a design pattern as a query string and fed it into the tool, then the tool can find whether there are instances of such pattern in the source after analysis. For more information, please see at : http://www.sosy-lab.org/~dbeyer/CrocoPat/
There has been some research in this area using Graph Grammars and Trace Diagrams. The trace diagrams can be used to find strong and weak patterns within program execution if you want to induce pattern recognition. Even without trace diagrams, a tree graph from the parser can be used to find (induct) general patterns in a program. However, for existing, or known, patterns, you may simply wish to use or develop a know set of grammar patterns and use a parser, such as SGG or VEGGIE, to "fit" the program's parse tree to the grammar. This may involve some generalization of the program's tree graph since specific implementation and language requirements will include many low level details in the parse tree that may not be very important to design pattern matching. Generalization of a parse tree can be automated, but you will probably need to develop a system that targets your specific needs.